[btipling]

I'd add to that to try and start using neovim. I've switched to it on Mac without a hitch and we (Floobits) have already moved our vim plugin to use the new neovim python-client plugin for much better async behavior. Making an async plugin for NeoVim is pretty trivial, here's a clock in your status bar:

https://gist.github.com/btipling/0d6faa80b24ccee5caea

Note this requires +python, :he nvim-python for how to get that (involves pip install neovim)

You can't do something like this clock in vim without the feed keys cursorhold hack that breaks using leader keys. Otherwise I'm still using vundle and have made 0 changes in my .vimrc other than move it all to .nvim and .nvimrc. All my plugins and vundle worked out of the box.

[sooheon]

I had put neovim out of mind and settled for emacs/evil, but seeing an actual use case for the new plugin system makes me hopeful for it's fast growth and adoption.

[teacup50]

Remember that floobits are the people that threw a tantrum when upstream vim wouldn't accept their patches, and have a vested ego interest in pushing a vim fork.

[avidal]

Source?

[StevePerkins]

Eh... unless there's more to the story that I'm missing out on, I don't think it's fair to say they "threw a tantrum".

Basically, that company has a service that lets developers do real-time collaboration. Like working on a Google Docs document... except that it's for code, and collaborators can all use whatever supported editors they like. When they went to add support for Vim, they ran into problems with the "real-time collaboration" part... because Vim is single-threaded and doesn't have a non-blocking event loop:

https://news.floobits.com/2013/09/16/adding-realtime-collabo...

So they kinda hacked together the means for a non-blocking event loop, and submitted it as a patch to Vim:

https://news.floobits.com/2013/09/17/adding-settimeout-to-vi...

The Vim maintainers kept rejecting it, for different reasons each time. After two months of back-and-forth, the Floobits guys asked the Vim guys to either give a comprehensive list of things in the patch that need to be different... or else acknowledge that they simply don't want the event loop thingy merged at all, and that Floobits should move forward with their own fork of Vim instead:

https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM[...

Personally, I don't have an opinion one way or the other on the merits of that patch. However, I think the Floobits guys were justified in feeling frustrated about the Vim guys dragging their feet and not being completely forthcoming.

Either way, if you do some quick web searching, you'll notice that Floobits became pretty big fans and online promoters of NeoVim from that time forward! So much so that you kinda have to take it with a grain of salt.

I'm not exactly sure what to even think about NeoVim. They've been plugging away for over a year, their GitHub repo has over a hundred contributors and two-thousand commits, and yet it's still pre-alpha? Also, the primary purpose seems to be allowing people to write Vim plugins in any programming language. However, it's not like the Vim ecosystem is hurting for plugins today. Besides, the whole point of "vimscript" is that it's self-contained and baked-in as part of the editor. Totally cross-platform, and always there. If I install a NeoVim plugin, then I have to make sure I have the right version of Ruby or Python or whatever on my box to support it? Yuck, no thanks.

As near as I can tell, any real value-prop for NeoVim is using it as an embeddable component. Like the Cloud9 guys' cloud-based Ace editor (http://ace.c9.io), or as something that IDE makers could bake into their desktop IDE apps. I don't really see what's compelling about it head-to-head with standard Vim, assuming it ever fully ships.

[ggreer]

That is an excellent summary.

teacup50 has an axe to grind. See:

https://news.ycombinator.com/item?id=7279358

https://news.ycombinator.com/item?id=7287939

https://news.ycombinator.com/item?id=7288699

[teacup50]

You're the one whose bad patches were rejected, you just dug through a year's worth of my comment history, and you're constantly and heavily promoting a terrible-design-and-still-no-beta-even-after-a-year-and-a-lot-of-donated-money fork of someone else's open source project ...

... and I'm the one with an axe to grind?

[kev6168]

Neovim will have Lua (and LuaJIT) baked-in too, so Lua will always be there.

In my opinion initially there might be many different languages used by developers as they try out the new versatile plugin infrastructure. But after a while only a few languages should emerge as the dominant ones, because developers have the desire to help as many people as they can by making their plugins easy to be deployed and configured. I would guess Vimscript and Lua(both baked in), Python(nowadays it's practically ubiquitous) are the more popular choices. Personally I like Go (fast, easy concurrency, and single executable deployment).

[tuhdo]

Imagine that one day you want to use 10 plugins and have to setup all 10 language environments to use those plugins, and you have to set the whole thing on Windows...

[sooheon]

You make a good point, and maybe nvim's decision to open up plugin languages will come back to bite it in the ass. It is a form of fragmentation in a sense, but I'm hoping the benefits will outweigh the drawbacks.

[Gracana]

Does vanilla neovim offer anything that a vanilla vim user might like? I imagine I will make the switch at some point, I just wonder if there's any compelling reason to do so sooner rather than later.

[btipling]

It's pretty much still the same experience. Once plugins that take advantage of the async and when gui's take advantage of the API I'm pretty sure neovim will not just be equal, but far superior.