Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vis: A Vim-Like Text Editor

github.com

Post reply on HN
Print view View original

141–150 of 166 posts

Re: Vis: A Vim-Like Text Editor

#141

Post by cloudhead »

lolsal wrote: post #86
cloudhead wrote: post #33

Earlier quoted context omitted.

The promise is that given it's a new, modern codebase, it could quickly outpace vim in capabilities and usability. Vim's legacy is what is holding the editor back from major improvements.

It sounds like you are saying it is better just because it is being written from scratch. I don't plan on contributing or writing any plugins to Vis (or vim) so I don't really care about what the 'guts' of the project look like as long as it does what I use it for (text editing). What motivation would I have to install Vis and deal with the mental overhead of switching (I am sincerely asking)? I have the same concern…

Yes. I would absolutely not advise to switch over at this point in time, unless you want to support the project. In its current state, I suspect it will be a poorer experience than vim and neovim.

Re: Vis: A Vim-Like Text Editor

#142

Post by martanne »

cm3 wrote: post #138
martanne wrote: post #24

Earlier quoted context omitted.

Yes from a design philosophy standpoint vis is closer to kakoune than {neo,}vim. The implementation is quite different though (no C++, no boost, no home grown scripting/extension/syntax highlighting language).

I don't use either, but to be fair, I wouldn't call vis's requirements lighter than kakoune. Vis needs Lua and libtermkey (which according to its author is EOL'ed) at build and run time.

Kakoune is a fine editor.

Regarding vis, Lua is optional (you lose syntax highlighting though). libtermkey is a 3 file library and despite what the author claims it works, is useful and could be maintained in the vis repository if necessary.

If you think anything C++ related is lighter than something C based, then we just have to agree to disagree.

Re: Vis: A Vim-Like Text Editor

#143

Post by cloudhead »

hyperbovine wrote: post #101
cloudhead wrote: post #33

Earlier quoted context omitted.

The promise is that given it's a new, modern codebase, it could quickly outpace vim in capabilities and usability. Vim's legacy is what is holding the editor back from major improvements.

What are the major improvements that cannot be added to Vim due to its legacy codebase? Honest question from a longtime vimmer.

One thing that comes to mind is that vim doesn't support multithreading very well or at all, when it comes to plugins. This is one of the issues Neovim is tackling.

Re: Vis: A Vim-Like Text Editor

#144

Post by qu4z-2 »

geoelectric wrote: post #123
aoloe wrote: post #61

Earlier quoted context omitted.

concerning vimdiff: one of the goal is to get vis to also work in server mode and be embeddable. it should then be possible to create a diff tool that uses vis for the editing.

So instead of the vim philosophy of embedding every functionality within vim, this potentially embeds vis in every functionality? I actually like that--much more composable.

I believe (and I may be wrong) that the vim philosophy is actually to embed vim in things rather than embed things in vim. They've just lost track of that a little over time.

See also :help design-not: 'Vim is not a shell or an Operating System. You will not be able to run a shell inside Vim or use it to control a debugger. This should work the other way around: Use Vim as a component from a shell or in an IDE. A satirical way to say this: "Unlike Emacs, Vim does not attempt to include everything but the kitchen sink, but some people say that you can clean one with it. ;-)"'

Re: Vis: A Vim-Like Text Editor

#145

Post by to3m »

mbrock wrote: post #54
rplnt wrote: post #51

I feared it would be written in javascript (it's on the front page of HN after all), but I was very positively surprised. There are projects where it's not appropriate to use node.js and the hell it comes with.

Can we please try to stop talking about this specific language ecosystem as an awful deplorable hell hole or whatever?

Can this specific ecosystem please stop being a massive pile of crap? Then maybe we can have something nice to say about it :)

Perhaps the new ECMAScript standard will help. I have my doubts (but as with any statement about the future it is hard to say with any certainty what will happen). The Node rot runs deeper than the usual Javascript nonsense.

If it feels like Javascript is being unjustly maligned: (a), it isn't; (b), wait for the next gnarly buffer overflow exploit to come along and you'll see that people despise C just as much.

Re: Vis: A Vim-Like Text Editor

#146

Post by dickson »

vbit wrote: post #140
loudmax wrote: post #50

Kudos to the developers for listing non goals. Too many software projects lose focus and become bloated because they take on features that are secondary to the main purpose. Projects may refrain from listing non goals for fear of excluding people who may want some of those features. And looking at the list, there are some pretty nice features excluded. For example network support, or editing compressed or tar files.…

For a non-vim user - can you describe what vimdiff is please?

vimdiff is a mode within vim to compare differences between buffers. It allows side-by-side comparisons like modern GUI diff tools by showing buffers in different 'windows' (vim screen splitting). You could also open multiple window in this mode to make vimdiff behave like a 3-way merge tool. It also has commands to pick hunks from different buffers into the merge buffer.

Re: Vis: A Vim-Like Text Editor

#147

Post by piokuc »

martanne wrote: post #22
Mossisen wrote: post #11

How would you compare this to the NeoVim project? https://github.com/neovim/neovim

Reposting an answer from a related thread. The main difference is that vis is written from scratch while neovim inherited an old and hard to maintain code base. This allows vis to experiment with various ideas: - native multiple cursors/selection support - structural regular expression support - different core data structure resulting in efficient large file support - LPeg based syntax highlighting - Lua as an in pro…

What are multiple cursors useful for?

Re: Vis: A Vim-Like Text Editor

#148

Post by gnuvince »

ageofwant wrote: post #29

Excellent. The more vim the better. I would like to see many of the core vim patterns replicated in other editors: - modal over chords - text objects - the vim "language" which ties it together - all the other good stuff, did I mention text objects ? There is a reason vim has more users today then ever before: once you learn the deceptively simple language you can have deep conversations with your editor.

The vim language would be better if it wasn't full of exceptions that have no reason for existing (e.g. `Y` is `yy` rather than `y$`, or `cw` and `ce` being equivalent while `dw` and `de` perform different actions).

Re: Vis: A Vim-Like Text Editor

#149

Post by tekproxy »

sea6ear wrote: post #130
rbonvall wrote: post #102

Earlier quoted context omitted.

The great thing about vim is that it'll always be there as a fallback. I keep a file with my passwords, encrypted with Vim's builtin encryption. Neovim removed that feature. If I ever switch to neovim, I can still use vim when I need to open that file.

TIL that Vim supports encryption out of the box. Thanks :)

here's some more interesting, related stuff on it - https://www.reddit.com/r/ReverseEngineering/comments/42v21h/...

Re: Vis: A Vim-Like Text Editor

#150

Post by hvis »

kromem wrote: post #56
irremediable wrote: post #38

One of these days, I'm going to sit down and try out this, emacs-evil, and neovim. Side-by-side. Need to figure out which one I like most.

I just switched from vim to neovim to evil. I can't see myself ever going back. (Neovim was basically just vim with async support, and terminals, but as a tmux user, that didn't really grab my attention). There's a lot more polish in the integrations for emacs than vim, likely as a result of literally everything in the editor being a function call that can be hooked into. The only thing I miss is solid tab functional…

> This same functionality sits as open tickets in the major vim autocomplete plugins

IIUC it works okay-ish in at least two of them: https://github.com/Rip-Rip/clang_complete and YCM after https://github.com/Valloric/YouCompleteMe/issues/36.

(Happy Emacs user and contributor here; just want all editors to stand on their merits).

Post reply on HN