Hacker News Reader

Comment by jmcdiesel | Hacker News Reader

I love VIM... but I feel like VIM's life is coming to an end... as VIM. NeoVIM is just... better. The editor as it stands now is essentially the same, but an actual active development that isn's a single contributor is going to create a better project, and its going to respond to the community more and keep itself more up to date and performant.

I feel bad, in a way, because i have a strong loyalty to vim, but Bram's stubbornness at playing well with others is basically holding onto sand, and we know how that analogy goes...

View on HN

"actual active development that isn's a single contributor is going to create a better project"

Depends on what your definition of "better" is. If you just want stable software that's bug free, multiple contributors might actually make the software worse. A lot of people use vim in a way such that Neovim will be no improvement.

Neovim could become like the next zsh. I use zsh every day and have for years. I think it's "better". But for most people bash is good enough so they use it. The things that are better in zsh are not things they care about, so they will not bother switching.

I'd be okay with that result (bash : zsh :: vim : neovim). Whatever the result I think vi(m) users are winning in the end. One side benefit of neovim existing is a push for vim to get similar feature and step up their development efforts. One difference I see with this comparison is neovim's goal: `feature-parity and backwards compatibility are high priorities`. If they succeed in this then there'd be little downside to switching.

Every mention of Vim turns into promotion of NeoVIM. Perhaps submit a story about NeoVIM if you want to talk about it. And what value do comments like this add? How am I better informed after reading it?

> NeoVIM is just... better

> an actual active development that isn's a single contributor is going to create a better project

Seriously? Since Vim was first released, probably there have been millions of software projects fitting the latter description that have not been nearly as successful as Vim. There are millions of them on Github right now. And don't forget the personal attack:

> Bram's stubbornness

If stubbornness produced Vim, we need a lot more stubbornness in software development.

>Every mention of Vim turns into promotion of NeoVIM.

I understand the frustration, but doesn't every Hacker News thread have a thread about alternatives (usually including some promotion)? I mean, every Vim thread includes a discussion of Emacs, too.

True, but as someone that visits places specifically for vim like (/r/vim) it get's particularly annoying. It's not that it's out of place here, is just a cumulative effect (for me personally anyway) from hearing about it where it doesn't belong.

I used vim for 20 years, up until about a month ago when I tried kakoune. It's got a new approach to modal editing that I really dig, which makes me realize the thing I loved about vim was that for a long time it was the best modal text editor around. I still think vim is a great project, but kakoune takes a refreshing approach that really clicked for me.

Don't hold back on us: What are the differences? The strengths and weaknesses?

Fair question!

Grammar: kakoune is heavily oriented towards selections. Things that happen in normal mode operate on the current selection. It's like using visual mode in Vim, except it's always on. It takes a little getting used to, since any cursor move changes the current selection. Part of its selection orientation is excellent support for multiple cursors.

Platforms: POSIX only. No support for odd platforms. If you want to use it on Windows, you have to use Cygwin.

Packaging: basically non-existant. You pull it from github and build it yourself.

Maturity: kakoune doesn't have version numbers as far as I can tell. I've had it crash on me, but it's rare.

Community: tiny but vibrant. There's #kakoune on freenode, which the core team seems to monitor pretty actively.

Syntax highlighting: yes, and it's more flexible than vim's. You can use it to roll your own colorcolumn, for instance.

Code folding and line wrap: these aren't there in kak, and I do miss them, but not enough to go back to vim

Tmux integration: awesome in kak, absent in vim. One of my new favorite things. In general, you can have multiple editors attached to the same session.

Automation / configuration: There's no such thing as kakscript, which I see as a plus. Nevertheless, you can do a lot of stuff here; I haven't scratched the surface, but there are lots of interesting example kakrc files out there.

Thanks for pointing out this project. It looks interesting.

Just to your point on packaging.. I googled and had it installed and running on Fedora in about 5 minutes after reading your post.

There are individual instructions and packages for many distributions listed here:

https://github.com/mawww/kakoune#2-getting-started

On Fedora it was literally 2 commands to install:

$ dnf copr enable jkonecny/kakoune ; dnf install kakoune

And then just "kak" to run it and play around a bit :-)

I suppose I must have seen those options and thought, "I might as well build it myself." I stand corrected!

Two main differences for who comes from vim in my opinion:

1) Editing model based on (multiple) selections. Instead of moving around and issuing verbs on objects, as in vim, you are always selecting something and the command (delete, change, yank and so on) comes afterwards.

It may not seem very different from vim, but the huge advantage is the feedback that you get from the editor.

2) Scripting kakoune is totally different from scripting vim and somewhat harder. If you need something in vim, you write your vim script and that's it. You can't do this in kakoune because the editor language is not a programming language, but only allows you to communicate with the system.

This is the reason why POSIX is a hard dependency, every script in kakoune usually relies on POSIX binutils to do things.

I've been learning to use UNIX more since I've started to use kakoune.

If your interested in text editors then it's worth watching some youtube videos on kakoune. There are some great ideas in there that even the old dogs could learn from. Actually, a lot of us could learn from it when it comes to things like feature discovery, it's a really good example of complex yet easy to use software.

The reason I haven't switched is because I prefer vims command->motion over kakounes motion-command, which doesn't quite sit well with me and because I don't like the scripting choices they made.

Can you point me towards some YouTube videos on kakoune? Literally cannot find one.

Sorry about that, I can't find any youtube videos either, I must be mis-remembering. I would recommend trying it out though, you don't have to spend long to see many of it's better features.

my take: the main strength and weakness is that kakoune is visual mode by default, so you see the effect of your text object commands without guessing (c3fx? c4fx?). having something always highlighted can be annoying.

Kakoune is neat, but the lack of a windows version makes it a non-starter for me (I need Windows, Linux, OSX to cover my use cases).

If running cygwin doesn't annoy the pants off of you, it works great in MinTTY/tmux.

If your running cygwin it's easy to build.

Thanks for the pointer. I am getting more and more frustrated with Vim (and neovim is not what I am looking for) and looking for alternatives.

I did try "vis" a while ago and it was alright but not quite there yet. And it was a bit too "sickness" for my taste, e.g. requires shell scripts for completion to ":open".

I do intend to try it again some time but I'll also give kakoune a go.

https://github.com/martanne/vis

I haven't tried vis, although it too looks like a pretty solid project.

> I did try "vis" a while ago and it was alright but not quite there yet. And it was a bit too "sickness" for my taste, e.g. requires shell scripts for completion to ":open".

With regard to that particular issue, kak has a great fuzzy-finder.

edit: It also apparently integrates with ranger, although I haven't tried that.

It works very well but is still work in progress.

I appreciate that it's "just an editor" and not a half-assed IDE or an application framework. But I think they might have taken it a step too far.

I've been using `vis` for a while now, and I agree that it used to be overly minimal, but I've submitted enough issues that it now fits my workflow. Once you get past the friction of it not being vim, you can enjoy multiple cursors, a sane scripting language (Lua), sam's structural regex....

Yes, it's time to start thinking about the next twenty years.

Moving vim from a single threaded process to more of an asynchronous server framework is the right move. Emulating vim commands in other editors just doesn't work, we need to turn the edit and command modes into a service.

I also like the endorsement on lua. I'm eager to move my scripting away from vimscript.

A HUGE advantage for vim is that you can login to any server, new or legacy, and it will have vim. At least it will have vi.

Guess it would depend a lot on the dev, but it seems like NeoVim would make sense for one's personal computer, and then Vi/m whenever logged on to a remote server.

I'm a vim neophyte, but it's not like your .vimrc follows you along to those remote servers anyways so things would be different anyways working on a server?

> but it's not like your .vimrc follows you along to those remote servers

It could follow you. In the recent discussion of TMUX some people said that they have remote systems configured in such a way that the personal config files are automatically downloaded when they login as their dedicated user. All you need to do is to put your dotfiles put your dotfiles on S3 (IIRC), download happens on first login (again, IIRC).

In other words, "your config doesn't follow you" is more of a philosophical problem rather than a technical one. Personally, I think it's a bit silly.

I mean, you wouldn't normally think of running Nginx, Supervisord, Redis, Postgres, etc. without config files, so why do you (people who are against personal configs on servers) insist that we use Vim, Emacs, Git, Tmux, etc. without one? Using Vim (less so than Emacs, but still) without your .vimrc is like using Nginx with default nginx.conf. You can still serve static files if you can find your htdocs dir after all.

A sane global (system-wide) config for the tools would solve some issues, but that's a first step towards personal customization (which, as mentioned, is unacceptable for some people), so in practice we're mostly stuck with nearly unusable tools when we work on remote servers...

Ok, I feel a bit better now, sorry for ranting :)

> but it's not like your .vimrc follows you along to those remote servers anyways so things would be different anyways working on a server?

That's why I don't really customize vim at all, or make fancy macros, or any of that. I work on a half-dozen different machines and OSes every week, I can't be bothered to customize those environments just to lose them every time I re-format.

You could just make config downloads automatic on all your servers, see my comment below.

Doing this - not using customizations - means you're forfeiting 70%-90% of functionality and power of those tools. I don't think it's smart, but well, it is your choice.

Can you describe what you like to customize? I find I spend far more time thinking about code than writing code.

> Can you describe what you like to customize?

With pleasure, actually! Just today I thought about writing a blog post on this topic and seeing your request made me resolve to do it.

I'll post a comment here once I'm done, thanks for waiting ;-)

Sounds cool :)

You can have a simple fabric script to copy .vimrc (and .alias, .bash_profile, etc) copied to a new server. You don't need sudo for any of this.

Doesn't have to be fabric, just a shell script with scp. If you can ssh to a server you can copy dot-configs to your $home dir.

my vimrc (and all my dotfiles) are kept in my private github so, with a single git command, they travel right to me... :)

This is so nice and so much easier than it seems. And there's no need for a private repo; unless you're ashamed of your dotfiles, you could keep them in a public repo.

They are in a private-ish... its my company's internal... because i do share it with coworkers, but it does setup a lot of environment variables specific to our products, so its not fit for general public consumption :)

I will agree once neovim ships on the major platforms and has functions on par with vim. Their next milestone for Windows support has continued to slip. It's been at 75% complete for many months. Meanwhile, gVim is running great on numerous platforms.

It's not a knock against neovim, but I just hope they can keep things going.

Is it possible that Windows users are not as interested in vim as *NIX users for historical reasons, and therefore don't care as much about support?

Where it works, it's a drop-in replacement for VIM, notwithstanding differences in async implementations now.

It's certainly not a drop-in replacement for vim. It doesn't support many features released in vim 8.

Until vim 8, it was a drop-in replacement, retaining full compatibility with vimrc and all plugins. My switch was seamless, and that was a big goal of theirs. Vim 8 introduced features already found in neovim in an incompatible way, and now the real fork begins.

Well it isn't a drop-in replacement now. And it wasn't a drop-in replacement before either, on the platforms they needlessly removed compatibility with.

Vim introduced features that had been being worked on since before NeoVim, in a way that actually made sense in the context of Vim, and which fit into Vim nicely.

When trying NeoVIM I found it completely unusable because of a single bug: https://github.com/neovim/neovim/issues/2035

Hitting ^[ needs to be utterly responsive, but this causes that input to take up to seconds to be accepted. I've tried the suggested workarounds in tmux, etc. but the problem stubbornly persisted so I gave up. Will have to check back once that is fixed.

This brings me to a larger point - with Vim I can throw just about any environment/file type/file size at it and expect it to work. NeoVIM is not there yet so it's going to stay on the "try again in the future" list.

I had the same problem in terminal Vim.

This fixed it:

    " leave insert mode quickly
    if ! has('gui_running')
        set ttimeoutlen=10
        augroup FastEscape
            autocmd!
            au InsertEnter * set timeoutlen=0
            au InsertLeave * set timeoutlen=1000
        augroup END
    endif

How is NeoVIM better than vim?

Never tried NeoVIM; VIM is very customizable, so for me its ok as long as I can customize it.

The most confusing vim thing for me was to learn vimscript (when doing plugins), but nowadays there is python so it shouldn't be such a problem.

This discussion caused me to look up info on it, and this source has some compelling reasons:

https://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-...

For me personally, a good reason to switch seems to be the NeoVim team itself seems less hostile to new people and making changes. Of course stability is likely important to many people, so there may be many good reasons to stay with vim as other's have stated, but someone refusing an update because it uses ANSI C seems a bit much...

I disagree. NeoVIM is clearly worse, to me. It has zero benefits over proper vim and many massive downsides.

Lucky you elaborated and supported your opinion with facts.

I have no loyalty to vim, but https://github.com/neovim/neovim/pull/2856 means I can't trust neovim.

What about updating a file on the buffer that is changed on the disk means you cant trust them? (Especially since its an option that can be toggled?)

There's the change, and there's what the change says about the project. The change violates the principle that what is in the buffer is there because the user caused it to be there. Since it is a silent change to a principle that vi and its descendants have always followed, it can lead to data loss; the copy in the buffer may have been the only one. The fact that the change was apparently entirely uncontroversial means that neovim does not think through the implications of their changes and/or is not sufficiently concerned about data loss.

Disclaimer: I committed that change.

If you think the issue is important, you are free to report it; the project has reverted decisions like this when people have complained (most recently, the default value of the `mouse` setting).

On the other hand, considering how much time this had to be discussed, I would think that by and large this is not a mayor concern for users. This commit was made In June 2015, and the discussion about defaults goes as far back as essentially the beginnings of the project in 2014. We inherited this setting from sensible.vim (which many people consider, well, a very sensible minimal configuration), where the issue was discussed and dismissed back in 2013 (https://github.com/tpope/vim-sensible/issues/64). I think the argument there is convincing. Again, if you don't, please discuss it in the appropriate channels.

Reply on news.ycombinator.com