5 ms·

As part of the neovim team and the author of the built in LSP for Neovim, I'd say that 0.5 is where things will really diverge. One of those factors is the buil

As part of the neovim team and the author of the built in LSP for Neovim, I'd say that 0.5 is where things will really diverge. One of those factors is the built-in LSP support, but the others are the ramping up of Lua plugins being written, the extranges/extmarks features being worked on, the treesitter integration, and some other features I won't mention for fear of drumming up premature hype. I completely agree with you otherwise. Neovim inspired Vim/Bram to kick things back into gear, and Neovim also took some inspiration from Vim's ideas, and the two have been close for a while, but the Lua integration is beginning to pay dividends which will cause a wider rift. Vimscript is not an ergonomic programming language or very performant compared to Lua, and I'm pretty sure that everyone can agree with that. E: Oh, and I plan to make an answer to KillerSheep for the 0.5 release that will hopefully be equally or more impressive. :P

caymanjim 7y ago
I'm looking forward to that. I've written a few plugins. Vimscript is fine for some stuff, but you can only do so much with it. I got deep enough in that I uncovered a bug with autoloaded dictionary functions. I wrote a pretty extensive unit test library for vimscript too, but then I threw in the towel and started writing plugins using Ruby and Python. Those were still pretty slow. I'm grateful to Bram for all he's done with Vim, but there are many inefficiencies in it, and the Vim source is extremely hard to work with and not well-factored. Just having neovim as a rewrite that's easier to modify is great. Thanks for all your hard work!
LadyCailin 7y ago
So, why aren’t you making these contributions directly to vim? Are the maintainers there not open to PRs?
- lohfu 7y ago
  Maintainer, not maintainers. If you look at the vim repo, https://github.com/vim/vim https://github.com/vim/vim, essentially all commits are from the same person. Encouraging contributions and splitting maintenance between multiple people was one of the key factors when forking neovim. IIRC neovim was a result of Bram, the vim creator, refusing a PR for async plugins. Functionality that is today regarded as extremely important.

caymanjim 7y ago

I'm looking forward to that. I've written a few plugins. Vimscript is fine for some stuff, but you can only do so much with it. I got deep enough in that I uncovered a bug with autoloaded dictionary functions. I wrote a pretty extensive unit test library for vimscript too, but then I threw in the towel and started writing plugins using Ruby and Python. Those were still pretty slow. I'm grateful to Bram for all he's done with Vim, but there are many inefficiencies in it, and the Vim source is extremely hard to work with and not well-factored. Just having neovim as a rewrite that's easier to modify is great. Thanks for all your hard work!

LadyCailin 7y ago

So, why aren’t you making these contributions directly to vim? Are the maintainers there not open to PRs?

lohfu 7y ago
Maintainer, not maintainers. If you look at the vim repo, https://github.com/vim/vim https://github.com/vim/vim, essentially all commits are from the same person. Encouraging contributions and splitting maintenance between multiple people was one of the key factors when forking neovim. IIRC neovim was a result of Bram, the vim creator, refusing a PR for async plugins. Functionality that is today regarded as extremely important.