The reason I ask is because one of the primary reasons I made the switch to Vim from TextMate is ubiquity and longevity. In the age of GitHub, fads, forks and abandoned projects have become all too common. Meanwhile Bram has proven himself to be a pillar-like benevolent dictator for decades, and to me that means a hell of a lot.
As for "getting behind it if it succeeds" lets hope not! I was a financial supporter of Neovim. I also have run the #vim channel on FreeNode for over a decade. They serve different goals.
Neovim is where "big changes" can happen, gut legacy support, move fast, break shit. It is on Github, it has multiple people doing major contributions, it is being re-factored to make it easier for MORE people to get involved. Neovim wants to be a huge community project, which is awesome.
Vim is -- the default on many systems, shipped with fully working vi compatible mode, has literally millions and millions of users. It can not -- by its nature -- move fast and break shit. Vim has a much, older, slower development process -- from the days well before Github and friends... it might slowly open up -- but not much, because again, millions depend on it. This is also, awesome.
I hope the very best ideas, once they are tested, debugged, and tested again will make their way up from Neovim to Vim, but it will be a very slow process. Neovim gives no thought to Vim -- because it can't -- it has to be its own thing to move forward. Vim gives no thought to Neovim yet -- it is an established, dependable, amazing tool... and Neovim has not yet risen to the point to even be worthy of a response.
The first thing done to Neovim was to re-format all the code and then do some refactoring that breaks things. You can't make an omelette without breaking eggs but this practically burned the bridges behind and any hope of merging stuff upstream/downstream from neovim to vim or vice versa is gone. At least without significant manual labor.
If you ask me, this was a premature move and the neovim guys should have tried to make non-breaking changes first with an opportunity for upstream-downstream merges.
The code had to be re-factored to let the community in -- the Vim code is a horrific legacy cruft-fest that terrifies even the most brave developers. But it is a historical working one, which is hard to argue with -- look at those styling commits, they are wonderfully sane.
What I'd rather see is vim with deprecations and upgrades on a reasonably timed roadmap. It's obviously a lot more work to maintain a 7.x branch, 8.x branch etc, but this is much more sustainable and meets everyone's needs better than saying "fuck it I just want Sublime with better vim bindings". An editor is not something where I want to chase the flavor of the month and deal with constant plugin breakages, but neither is it something where I want to be stuck in the 90s forever. There has to be a middle ground.
For the time being Bram's approach has earned my trust, and Neovim has to demonstrate many years of good project management and momentum before I will really be willing to trust it.
But, that misses the point of Neovim a bit -- Neovim is about letting the community in (with all the good, and bad that comes with that). I suspect most people won't shift over to Neovim until either (1) They want to actually contribute something and find Vim proper far too daunting, or (2) because of the entirely new plugin model, some amazing plugin is only available on Neovim and it drags them over from Vim.
The Neovim plan seems to be "in months to gain momentum, in years to gain trust" -- which is really the only way you can do it.
It's going to be an awful lot of work, with the result that not all
systems will be supported, new bugs introduced and what's the gain
for the end user exactly?
Total refactoring is not a solution. It's much better to improve what
we have. Perhaps with some small refactorings specifically aimed at
making Vim work better for users.
A very good way of thinking.
For selfish reasons I'm behind neovim but I can see that it puts Bram in a bad position, which is unfortunate. He's done so much work for all of us (vim users), and ultimately this project just adds to the work he has to do (and makes it even more thankless). He'll be dealing with incompatibility issues between plugins trying to support both systems.
Ultimately, I guess he'll have to make a choice as to which codebase to support, by choosing neovim he's deserting everyone on esoteric systems. I think that may be the best outcome; Neovim becomes the new standard, Bram switches over and leaves vim to die. But then what control does he have?
It's one of those situations, it seems like a good idea, and could be a massive net win. Then again, it could also really destroy the project.
[0] https://groups.google.com/forum/m/#!topic/vim_dev/x0BF9Y0Uby...