[halostatue]

This is also a sanitized version of the truth.

Neovim was never a continuation. Bram has never stopped developing Vim.

As I understand it, the people behind Neovim developed some async patches which were not accepted by Bram for various reasons, and there was an ongoing discussion. Rather than reworking them to something that Bram thought was acceptable, they performed a hard fork. In the process of hard forking, they removed everything that they considered unimportant. This included gvim, support for older OSes, etc.

Vim has not, to the best of my knowledge, copied any features back from neovim, although it does now (shortly after Neovim forked) have async features (written with an API and user surface that Bram prefers) and various other features that may be similar.

Please note that Vim has had Lua, Ruby, Python, Perl, and other scripting language support for a very long time. The main difference is that rather than being compiled as an add-on and using bridging, neovim has added a Lua engine into the core (increasing complexity that way) and creating a DX-poor bridge for common vim configuration things so that startup scripts can be written in Lua.

Yes, Bram started working on Vimscript9 late, but your characterization of the history also is (unintentionally?) dishonest in that Vimscript has had extensive expansion and updates through time.

Neovim is not and has never been a continuation of the Vim project, despite their press. It has always been a hard fork that is getting increasingly incompatible with the source project, and I personally find it less usable than Vim because there’s not a single good GUI for it (there are several which may eventually become promising, and there are several which have taken bizarre directions like Oni2 did).

[0cf8612b2e1e]

>… neovim has added a Lua engine into the core (increasing complexity that way) and creating a DX-poor bridge for common vim configuration things so that startup scripts can be written in Lua.

And one can look at the explosion of new Lua-based plugins that have been developed because of it. People hated Vimscript. Now that there is a better first class language (guaranteed! Not dependent upon the host environment or compilation target), NeoVim is gaining some of the plug-in functionality that had previously been Emacs exclusive.

Edit: fixed autocorrect

[w0m]

> Vim has not, to the best of my knowledge, copied any features back from neovim

vimscript9, terminal, async among others. NeoVim was a kick in the pants for Bram to pull Vim into modernity.

[halostatue]

This characterization is false on all counts.

Neovim provided Bram competition, but he has not copied those features from Neovim.

vimscript9 doesn’t look or act like Lua (it still acts like a first-class citizen, unlike Lua) even though it is definitely improved over the previous version.

There have been terminal scripts for a while, but adding virtual terminal support was something resisted because a lot of people ran vim in a tty or with tmux. (Strictly speaking, terminal support is only something that to me makes sense for gvim and the like, otherwise you’re getting into terminal emulators all the way down. So much for the neovim philosophy of ripping unnecessary things out.)

And async was the entire reason that Neovim hard forked from Vim. Bram did not like the patches and asked for changes. The Neovim developers didn’t like the changes, so they hard forked. Bram implemented the async features / API surface that he wanted shortly thereafter.

There is a constant push from the Neovim camp that Vim is stagnant, backwards, dead, etc. None of this is true, and the messaging should absolutely stop. Frankly, I’d be happier if they rebranded from Neovim, because IMO they’re not vim and have stopped caring about compatibility with vim.

[w0m]

> There is a constant push from the Neovim camp that Vim is stagnant, backwards, dead, etc. None of this is true, and the messaging should absolutely stop. Frankly, I’d be happier if they rebranded from Neovim, because IMO they’re not vim and have stopped caring about compatibility with vim.

I have happily used (Brams) Vim the majority of my career; some daliances into PyCharm or VSCode here and there.Prior to the NeoVim fork; Vim felt.. slow.. to adopt new features. I was OK with that generally. 5 years for Vim7 to come out was the biggest gap, before Vim8 released after a decade gap (with NeoVim getting forked ~halfway through). Each major release taking longer than the previous. You can say Vim development hadn't slowed; but major releases did; with a ten year gap was concerning.

I don't say that as a negative on Bram, but 10 years between major releases is an eternity in the modern programming world - I'm glad he's refocused, Vim-9 is a huge leap forward.

[CorrectHorseBat]

>Strictly speaking, terminal support is only something that to me makes sense for gvim and the like, otherwise you’re getting into terminal emulators all the way down.

Terminal is what allows plugins such as fzf.vim to work, I think it's amazing.

I only welcome the competition between vim and neovim, I think it's been a great improvement to the ecosystem.

[halostatue]

Competition is fine. The neovim project and supporters shading the truth on its background, motivations, etc. is not.

[typon]

I dont know if its me but I find it utterly incomprehensible to read any Lua plugin in neovim. The API is magic and Lua itself isnt a very good language. That is to say, it didnt really get any better than vimscript. Ive written a couple of plugins in vimscript back in the day so i know the pain.

[st3fan]

"Lua itself isnt a very good language" is very subjective.

The API is pretty well documented now I think? If there is a specific area that isn't, then file a bug or write the docs. It is an open source project and thus is heavily depends on people contributing to make things better.

[typon]

I use neovim heavily and I spend the first five minutes of my morning thanking the developers for their hard work - without their selflessness we wouldn't have the best text editor in the world. I was just commenting on whether the purported benefits of using Lua over Vimscript as the core scripting language really panned out. Clearly a lot of people think they did.

[hwayne]

I haven't implemented this yet, but one thing I'm looking forward to is lua libraries. I have a data YAML that carries some autocomplete information. To use it with a vimscript function I had to convert it to a JSON first. With lua I should be able to use a library to just read the YAML directly.

[halostatue]

I disagree that Lua isn’t a good language. As a general purpose language, it is better than Vimscript, which sort of expanded into a general purpose language by fits and starts, and often not very cleanly.

Vimscript9 fixes some of this, but it is still focused on being a special purpose language (scripting vim) far more than being a general purpose language.

I agree with you that the neovim / Lua bridge is substandard and poorly documented, and way too magic. There’s too much distance between Lua and the vim model that isn’t well bridged by the API that has been written.

Certain things are better for neovim with Lua, because you can (in theory) take advantage of all that Lua has via luarocks. But that bridge back to the editor is still ugly, and I don’t like it.

[badosu]

I find the opposite being the case for me, it's a joy for me reading plugin code now and being able to understand and easily modify it.

[doix]

> and I personally find it less usable than Vim because there’s not a single good GUI for it

What features do you use from gvim? I used to switch between them, but I hated updating the vim font when I decided to change my terminal font, so eventually I just switched to the terminal version full-time. It's been over 10 years at this point, but I don't remember anything useful in gvim.

[halostatue]

The OS clipboard integration, the good font hinting and rendering, better colour rendering, the fact that the terminal doesn’t intercept some keyboard strokes. There’s a bit more, but I also find vim in the terminal to be less responsive overall than gvim.

I’m using MacVim as my gvim, but as I’ve indicated, the amount of code in MacVim is fairly small over that in gvim.