I am convinced that Vim's greatest asset and risk is Bram Moolenar. Bram is a talented, experienced developer, and I commend him for creating Vim. But he is the only person with write access to Vim's codebase. The primary author of NeoVim is Thiago de Arruda. Thiago tried to work with Bram, but was rejected.[1] Patches similar to Thiago's have been proposed before, but were also rejected.[2] It is for this reason that Thiago has forked Vim, and I wish him luck.
It's important to remember that everyone involved is trying to improve Vim as they see it. I think this is a prime example of how the benevolent dictatorship model can fail.
Do users mind that in your words Moolenar is a risk to vim, though? Are people specifically interested in the advancement of vim or just more generally in the progress of vim-like text editors, in which case they can happily switch to neovim if it becomes better than vim?
I wrote to Thiago about this already, but we don't even need multi-cursor support - just a few additional hooks so we can implement a multi-cursor plugin.
Although to be honest, making it part of core is vastly preferable, since it is a hard feature to get right (e.g., how do you deal with copy-pasting into multiple-cursors)?
I feel like one of the main goals of neovim is to make it more like emacs. Or guile emacs.
Instead of a shitty language for plugins and configuration: vimL (with some support for plugins in alternative languages but not well integrated and not present in all vim installations) and replace it with a good interface to a single language. Like emacs. Much of emacs is written in elisp instead of c, I wonder if this will enable quicker/higher level development with lua for parts of neovim.
The plans for a compatibility interpreter for vimL on top lua sound a lot like the elisp on top of guile plan for guile emacs, and isn't one of guile emacs goals to add support for concurrency?
Thiago claims that one of Vim's biggest problems is its lack of testing infrastructure. It is difficult to refactor or make changes without the chance of introducing some possibly obscure regression. This is probably a big part of Bram's reluctance to merge large changesets from other developers.
I honestly thing if he can successfully pull off this "msgpack UI" and get a solid set of tests written (which the community seems eager to start work on) this project will be a huge success.
Here is his quote from the mailing list:
"This may not be so obvious, but vim's biggest problem has nothing to do with the lack of the above features. It's something much more basic: poor testing infrastructure.
While vim has some automated tests(about 200 counting with the ~100 tests embedded in test 49) those only catch the 'biggest' bugs, with many small ones being introduced by patches and only detected at a later time. It's a true maintenance hell, and here's a post on reddit that illustrates the problem(even though the author himself disagrees with neovim): http://www.reddit.com/r/programming/comments/1yjzez/neovim_a...
The problem is that in it's current state, vim cannot grow because there's no easy way to write automated tests for it. The current test suite is very hard to understand and those that submit patches probably won't write tests because it's too complicated. But patches need to be tested, especially bug fixes which must acompany a regression to ensure they won't be reintroduced. So it's easy to see why Bram is skeptical about merging patches, especially new features: He has no way of knowing if those patches will break existing code. In the example given by the reddit comment, Bram 'solved' the problem by simply picking the lesser of two evils.
This is one of the firsts issues neovim aims to fix: By writing a msgpack 'UI', we'll be able to write well-documented functional tests in a high-level language. Contributors reporting bugs will be able to reproduce them with a test cases and new features will be properly tested. As the test suite covers more code, neovim will be more 'protected' since there will be a bigger chance of catching bugs the minute a PR is sent(with travis). People need to understand that before posting issues regarding new features or new ideas, as neovim must be properly 'secured' against bugs first."
The whole approach makes a lot of sense. Successful refactoring goes hand in hand with setting up a test environment. Code that is not covered by unit tests is legacy code. Without tests, you have to fear breaking things and fear is a bad starting point for development.
I backed Neovim and I really hope that it succeeds. I think the Vim codebase is criticized a little too harshly in general. It is a child of its time.
Whether Lua is the optimal choice as an extension language remains to be seen, yet it is a very pragmatic choice and over time we will see that the C core of vim will shrink dramatically.
I seriously hope that Bram Molenaar is not offended by the fork (and I think he is not). For the vim community having neovim as an independent development line will have its merrits until it is clear whether the fork can replace the proven editor.
Do we know how Bram feels about Neovim and whether he is willing to get behind it if it succeeds?
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.
Bram has said very little. He, IMHO, massively underestimates the communities desire to contribute... Neovim simply tapped in to a community desperate to improve a project they love, and finding no good options on howto do so.
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.
Quoting his answer [1] in the vim_dev mailing list:
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.
I've only seen his original post on it [0] - not sure if anything had changed since then.
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.
Others have probably already said this elsewhere, but I think high quality error messages for vimscript (or the lua api) are one of the most important things. The project already cares about the developer experience for people writing plugins. Error messages are a difficult but important part of that.
I've always wanted to write Vim plugins, but Vimscript and the RPC contortions always looked too hairy for me to get involved -- I'm excited for the new vim-embedding interface so I can get real VIM compatibility with my IDEs.
I tried it. For now it just behaves the same as normal Vim. Most of the work done is indeed under the hood. They are refactoring the codebase so that it will be easier to create plugins, extentions and to use Neovim inside other apps.
The goal (as I understood it) is to separate back-end and front-end. That is, you could have a CLI front-end with just text interface, or a GUI front-end with all the fancy features.
They are willing to make it more like gvim, running in a separate window, and one of targets of neovim is to use a modern graphics backend to achieve that.
[+] [-] chroma|12 years ago|reply
It's important to remember that everyone involved is trying to improve Vim as they see it. I think this is a prime example of how the benevolent dictatorship model can fail.
1. https://groups.google.com/forum/#!topic/vim_dev/65jjGqS1_VQ
2. https://groups.google.com/forum/#!topic/vim_dev/-4pqDJfHCsM%...
[+] [-] omaranto|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] edanm|12 years ago|reply
I wrote to Thiago about this already, but we don't even need multi-cursor support - just a few additional hooks so we can implement a multi-cursor plugin.
Although to be honest, making it part of core is vastly preferable, since it is a hard feature to get right (e.g., how do you deal with copy-pasting into multiple-cursors)?
[+] [-] beaumartinez|12 years ago|reply
Macros and global replace already do what you want.
[+] [-] hk__2|12 years ago|reply
[+] [-] Morgawr|12 years ago|reply
[+] [-] Afal|12 years ago|reply
[+] [-] rat87|12 years ago|reply
Instead of a shitty language for plugins and configuration: vimL (with some support for plugins in alternative languages but not well integrated and not present in all vim installations) and replace it with a good interface to a single language. Like emacs. Much of emacs is written in elisp instead of c, I wonder if this will enable quicker/higher level development with lua for parts of neovim.
The plans for a compatibility interpreter for vimL on top lua sound a lot like the elisp on top of guile plan for guile emacs, and isn't one of guile emacs goals to add support for concurrency?
[+] [-] Simucal|12 years ago|reply
I honestly thing if he can successfully pull off this "msgpack UI" and get a solid set of tests written (which the community seems eager to start work on) this project will be a huge success.
Here is his quote from the mailing list:
"This may not be so obvious, but vim's biggest problem has nothing to do with the lack of the above features. It's something much more basic: poor testing infrastructure.
While vim has some automated tests(about 200 counting with the ~100 tests embedded in test 49) those only catch the 'biggest' bugs, with many small ones being introduced by patches and only detected at a later time. It's a true maintenance hell, and here's a post on reddit that illustrates the problem(even though the author himself disagrees with neovim): http://www.reddit.com/r/programming/comments/1yjzez/neovim_a...
The problem is that in it's current state, vim cannot grow because there's no easy way to write automated tests for it. The current test suite is very hard to understand and those that submit patches probably won't write tests because it's too complicated. But patches need to be tested, especially bug fixes which must acompany a regression to ensure they won't be reintroduced. So it's easy to see why Bram is skeptical about merging patches, especially new features: He has no way of knowing if those patches will break existing code. In the example given by the reddit comment, Bram 'solved' the problem by simply picking the lesser of two evils.
This is one of the firsts issues neovim aims to fix: By writing a msgpack 'UI', we'll be able to write well-documented functional tests in a high-level language. Contributors reporting bugs will be able to reproduce them with a test cases and new features will be properly tested. As the test suite covers more code, neovim will be more 'protected' since there will be a bigger chance of catching bugs the minute a PR is sent(with travis). People need to understand that before posting issues regarding new features or new ideas, as neovim must be properly 'secured' against bugs first."
[+] [-] wirrbel|12 years ago|reply
I backed Neovim and I really hope that it succeeds. I think the Vim codebase is criticized a little too harshly in general. It is a child of its time.
Whether Lua is the optimal choice as an extension language remains to be seen, yet it is a very pragmatic choice and over time we will see that the C core of vim will shrink dramatically.
I seriously hope that Bram Molenaar is not offended by the fork (and I think he is not). For the vim community having neovim as an independent development line will have its merrits until it is clear whether the fork can replace the proven editor.
[+] [-] dasil003|12 years ago|reply
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.
[+] [-] MetaCosm|12 years ago|reply
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.
[+] [-] bpierre|12 years ago|reply
[+] [-] aidos|12 years ago|reply
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...
[+] [-] CyberMuz|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] mikaelj|12 years ago|reply
I'd prefer if they could be renamed to "Fetaure X which enables e.g. sublime minimap" and dito for autocomplete.
[+] [-] hk__2|12 years ago|reply
[+] [-] joshgel|12 years ago|reply
[+] [-] dang|12 years ago|reply
[+] [-] afarrell|12 years ago|reply
[+] [-] gaving|12 years ago|reply
[+] [-] jitl|12 years ago|reply
[+] [-] seren|12 years ago|reply
[+] [-] gitaarik|12 years ago|reply
[+] [-] threatofrain|12 years ago|reply
Can anyone else speak to the health of the project?
[+] [-] joelthelion|12 years ago|reply
[+] [-] manolus|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] rektide|12 years ago|reply
[+] [-] gcao|12 years ago|reply
[+] [-] js2|12 years ago|reply
[+] [-] SeoxyS|12 years ago|reply
[+] [-] kachnuv_ocasek|12 years ago|reply
[+] [-] martius|12 years ago|reply
[+] [-] indralukmana|12 years ago|reply
*i am going to run now.
[+] [-] cube_yellow|12 years ago|reply
[+] [-] pekk|12 years ago|reply
[+] [-] hedwall|12 years ago|reply