5 ms·

“Continuation” is a nasty lie when the original is by no means discontinued or dormant.

israrkhan 4y ago
If you look at vim commit history, it was pretty much stagnant for a long period of time, and then activity picked up in 2016, when it finally got competition from neovim. IMO governance model for vim, is not much receptive to community contribution, while neovim is more open. Looking at commit history and contributors graph on github seems to validate this.
turndown 4y ago
You’re right, at one point nvim was a continuation, but no more. For example nvim significantly cleaned up and reorganized and rewrote vim’s C code, they added complex new features like Lua config, floating windows, better plugin support. Vim copied many features they released independently… maybe vim is the continuation here now? I think one of my favorite things about vim the continuation is that after sitting on a terrible config language for >2 decades somehow when nvim released Lua support all of the sudden vim was working on a new incompatible version of vimscript.
- halostatue 4y ago
  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).
  - typon 4y ago
    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 4y ago
      "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 4y ago
        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 4y ago
        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 4y ago
      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.
- sigzero 4y ago
  It was never a "continuation". It was always a hard fork.
- Beltalowda 4y ago
  VimScript has been in development for 30 years now. There has been support for many other languages (including Lua) for over 20 years, well before Neovim was a thing. The idea that Vim9Script is only due to Neovim is one of those weird ideas that I will never understand. I don't especially like Lua as a language (it's okay-ish, I guess, but not great), and I certainly don't think it's a good fit for a Vim configuration language, but it's okay to disagree on that. But it seems that some people are unable to comprehend that some people don't think that Lua is a gift from heaven for Vim. Vim9Script is very similar to "legacy VimScript", but with slightly different syntax and typing. Overall, I'd say is less of a breaking change than Python 3 was, and it's not like Python 3 is a "new language": just a continuation of the >20 years of Python 1 and 2 before it.

If you look at vim commit history, it was pretty much stagnant for a long period of time, and then activity picked up in 2016, when it finally got competition from neovim. IMO governance model for vim, is not much receptive to community contribution, while neovim is more open. Looking at commit history and contributors graph on github seems to validate this.

turndown 4y ago

You’re right, at one point nvim was a continuation, but no more. For example nvim significantly cleaned up and reorganized and rewrote vim’s C code, they added complex new features like Lua config, floating windows, better plugin support. Vim copied many features they released independently… maybe vim is the continuation here now? I think one of my favorite things about vim the continuation is that after sitting on a terrible config language for >2 decades somehow when nvim released Lua support all of the sudden vim was working on a new incompatible version of vimscript.

halostatue 4y ago
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).
- typon 4y ago
  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 4y ago
    "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 4y ago
      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 4y ago
        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 4y ago
    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.
sigzero 4y ago
It was never a "continuation". It was always a hard fork.
Beltalowda 4y ago
VimScript has been in development for 30 years now. There has been support for many other languages (including Lua) for over 20 years, well before Neovim was a thing. The idea that Vim9Script is only due to Neovim is one of those weird ideas that I will never understand. I don't especially like Lua as a language (it's okay-ish, I guess, but not great), and I certainly don't think it's a good fit for a Vim configuration language, but it's okay to disagree on that. But it seems that some people are unable to comprehend that some people don't think that Lua is a gift from heaven for Vim. Vim9Script is very similar to "legacy VimScript", but with slightly different syntax and typing. Overall, I'd say is less of a breaking change than Python 3 was, and it's not like Python 3 is a "new language": just a continuation of the >20 years of Python 1 and 2 before it.