| 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." |
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.