Hacker News Reader

Comment by mcjiggerlog | Hacker News Reader

I've never touched neovim as I'm perfectly happy with vim - what reasons are there for me to consider making the switch?

I would guess neovim isn't even on the radar of most vim users. I don't see neovim surpassing vim any time soon, personally.

View on HN

The honest truth is that almost everyone will have the same exact experience in neovim as in vim, and that the differences right now (this could always change) are mostly for developers hoping to use vim in a creative way. For example, nvim has a decoupled back end, so ides could emulate vim without having to do emulation at all -- they would literally just communicate with the neovim backend. Another example, which I think is great, is that to support python extensions, nvim does not need to be recompiled. A third one, which is perhaps the least valuable but is also the most user-facing, is that you can now open terminals within neovim. Of course, you can do this with vim and tmux, but sometimes it's nice that I can set up a binding for <leader>-t to open a terminal, or <leader>-p to open an ipython shell instead of using tmux's more cumbersome default bindings. That said, there are of course ways to set up fantastic tmux bindings, I just haven't.

I love neovim, but the idea that "most people use nvim" or "vim is dying" is just wrong. Though I really do think nvim's development philosophy will lead to better results than Moolenaar's.

What's really useful about the inbuilt terminal is that it's hooked up to the job control bits, which lets you do things like feed chunks of text to whatever happens to be running in it. I've got this set up as an operator[0] (fair warning, it's been a while since I've tested this much, and there are a few things it could probably do better), which is handy for, as an example, running python/irb/whatever in the terminal and sending function definitions to it as you write them.

EDIT: For the sake of being equal-opportunity, you can do the same thing in emacs with make-comint, even down to having it as an operator if you're using evil-mode. Y'know, whatever you're into.

[0]: https://gist.github.com/Wibjarm/5ae4c4da57bd034d15123cd8edad...

Neovim's popularity is more with extension developers. My understanding is that it enables them to develop features rivaling those in IDEs. Vim users won't switch for Neovim itself, but they might if extension writers only target Neovim.

I think Neovim also has a pluggable engine, so IDE vim emulators can simply include that portion rather than implementing the functionality per platform.

This was true for a while, but vim 8 (and some of the last patches of vim 7) added async tasks, channels and built-in JSON encoding/decoding. It's a hassle to have to support two different interfaces, but I suspect most plugin authors are going to do that rather than force their users to use neovim. Some plugins (like neomake) already support both.

Edit: Forgot to mention, many of the improvements in vim 8 were clearly in reaction to Neovim's innovations. Both projects benefit from the other, this isn't a fight to the death.

Can you name a couple of extensions that somebody considering Neovim should look at?

neomake (async execution of tasks like compiling, linting and syntax checking) and deoplete (for async autocompletion).

Neovim's async already has tremendous plugin support and is most obviously felt in new build plugins like neomake that do async linting--no more locking up the interface on saving, and this already works well.

Neovim's embedded terminal also works great and is something vim doesn't have.

Neovim is simple to try out because it's a drop-in replacement--all your old plugins will likely work out of the box, along with your .vimrc.

> what reasons are there for me to consider making the switch?

There are numerous improvements and features but I'll not talk about them. It has the momentum. Hundreds of developers are contributing to it. That should be the biggest reason to switch as it directly means Neovim will be much healthier than Vim which lacks the momentum.

If you want to know more about what exactly Neovim is doing on the technical side, I suggest you read up the 7 newsletters [0] since the inception of Neovim.

[0] https://neovim.io/news/

Features might be a compelling reason to switch. The fact that something is furiously developed by hundreds of developers is a very poor reason. What does this rather meaningless "health" of Neovim gives to the end users? Fresh new bugs?

I'm not arguing that there are no good reasons to try Neovim. I just don't see any logic in your argument. You speak about loosely defined "health" and "momentum" as if there was a clear link between software quality and amount of buzz around the project.

> The fact that something is furiously developed by hundreds of developers is a very poor reason. What does this rather meaningless "health" of Neovim gives to the end users? Fresh new bugs?

It's not like Neovim (or any open source project) is an open house where anyone can come, throw some code over the wall and get it merged. Like any big project (Vim included), it is being maintained by a set of core responsible developers who know better. Neovim has a huge focus on automated tests and CI also. I don't see any reason why a big contributor base should make the end product worse.

> I just don't see any logic in your argument. You speak about loosely defined "health" and "momentum" as if there was a clear link between software quality and amount of buzz around the project.

Of course there is. Look at Linux, ReactJS, Docker, Kubernetes, Ubuntu, Firefox. The more momentum a project has, the more contributions it gets. Open source projects succeed because of the community around them.

GNU Hurd was not able to gather momentum and look where it is today. Contributors flocked to Linux so it flourished.

> The more momentum a project has, the more contributions it gets

that's not disputed. the question is, what specific impacts do these contributions have on me, the user? why should i, a user of vim, switch to neovim?

async plugins? true color support? If you have a 32-bit color capable terminal you can use any colorscheme and get real RGB colors.

Those are very good and appealing features. Nobody questions that. On the contrary, the point is that those features are meaningful and valuable for the users. The amount of code and people used to implement them is not.

That got me: https://github.com/neovim/neovim/wiki/FAQ#how-can-i-change-t...

It feels faster to me, but I haven't compared to vim 8. I don't use any plugins doing work in the background, so that's not the difference here.

you can do that in vim as well http://pastebin.com/LLm0tx88

TBF that is non standard behavior and won't work everywhere.

That's interesting! I guess, neovim's behavior is just a convenience wrapper around this, then.

Reply on news.ycombinator.com