6 ms·

Neovim is a continuation of Vim, you can find more info here: https://neovim.io/charter/ https://neovim.io/charter/ Edit: This doesn't mean Vim is discontinued

Neovim is a continuation of Vim, you can find more info here: https://neovim.io/charter/ https://neovim.io/charter/ Edit: This doesn't mean Vim is discontinued.

halostatue 4y ago
s/continuation/hard fork/ Neovim is a hard fork, not a continuation. Vim is still being developed by Bram and other contributors, and has a lot of the same functionality now with different API surfaces. Questionable choices by both development groups (but, IMO, mostly from the initial arrogance of the neovim developers) are increasing the gap to the point where, in a couple of years, I do not expect there to be meaningful compatibility between them. A lot of people don’t like Vimscript, but I personally find the Lua integrations which neovim has to be harder to use because the language isn’t built around the editor, it requires bridging, and there’s a definite impedance mismatch involved. For me, without an equivalent of `gvim`/`MacVim`, neovim is a non-starter. The OS-level integration is important, and none of the various neovim GUIs that exist are nearly as good as the original `gvim` for X or Windows or MacVim for macOS.
- israrkhan 4y ago
  I find lots of arguments about who was actually more arrogant. But lets look at it from objective perspective. Looking at neovim[1] vs vim[2] contribution Bram is top contributor for vim. 16,211 commit right now. Second top most contributor has 194 commits only. Neovim top contributor has 2285 commits, followed by 21,66 commits for second. It looks to me that neovim is more open to community contribution. Then look at commit graph over period of time. It looks like Neovim is more actively developed. There development activity level around vim also increased in 2016. Perhaps that was the time when bram realized that he need to do more with vim, to compete with neovim. I myself was a longtime vim user, who switched to neovim 2 years ago, and am happy with it. [1] https://github.com/vim/vim/graphs/contributors https://github.com/vim/vim/graphs/contributors [2] https://github.com/vim/vim/graphs/contributors https://github.com/vim/vim/graphs/contributors
- kurtreed 4y ago
  What did you find arrogant about the neovim developers?
  - halostatue 4y ago
    Pretty much everything, including the ongoing lie that Neovim is a "continuation" of Vim. I replied in a different comment (https://news.ycombinator.com/item?id=33922783 https://news.ycombinator.com/item?id=33922783) about the async patches, which is where the whole things started. Because the patches weren’t accepted as is, they hard forked. That requires an incredible amount of arrogance. Neovim is not better than Vim. It is (increasingly) different. They have made different choices, some of which are interesting, some of which are baffling, and most of which are just different, although I consider the removal of GUI support to be about as arrogant as the gemini protocol stuff. There is a pernicious strain of software developer that thinks that they know better on everything and that GUIs are bad. I felt that way in 1992 or so, despite having been exposed in 1990 to X, because it was easy to pick on Windows 3.1 and (then) Mac users. I got over it because there are things which are better, easier, and faster with GUIs than without. Not everything needs a GUI, but if you want people to use your software, leaving it in the terminal is unlikely to be a long-term success strategy.
    - soperj 4y ago
      > Because the patches weren’t accepted as is, they hard forked. They weren't accepted for years, and if you're being honest, they never were going to be accepted. I'm guessing you thought Bram was also arrogant for forking vi?
      - halostatue 4y ago
        You’re right. They weren’t going to be accepted, because they didn’t work the way that Bram thought they should and the people who pushed them would not change them to fit Bram’s goals. As package maintainer myself, if I get a PR/patchset the implements something in a way with which I disagree, I will not accept the changes. If I don’t care enough about the changes, then I probably won’t implement them either. Or I might do so later when I have time. On the history of things, please be more precise. Bram did not fork vi. He worked from the Stevie code, which only ran on the Atari ST, so that he could use it on Amiga. It quickly expanded to other systems (I believe I encountered it after trying other DOS-based vi-like editors). That expansion eventually made it into the relative juggernaut it is today.
- shmerl 4y ago
  I'm glad for neovim addressing issues that vim ignored for years. The fact that vim picked some of those features is competitive pressure.
- sodapopcan 4y ago
  Hard agree on lua v. viml. Viml really isn't that bad. I'm certainly not claiming it doesn't have its warts and shouldn't keep improving, but it's a DSL for a text editor... And as you point out, you still need to know a bunch of viml that you have to wrap in Lua calls. At the same time, I haven't actually given vim scripting in Lua a fair shot, so I'd be happy if anyone could shed some light on why they might think it's better.
- wirrbel 4y ago
  > but, IMO, mostly from the initial arrogance of the neovim developers Vim really was in a sad state prior to the fork which turned out to be a wake up call to Bram it seems.
microsoftdoes 4y ago
“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).

Neovim is a continuation of Vim, you can find more info here: https://neovim.io/charter/ https://neovim.io/charter/ Edit: This doesn't mean Vim is discontinued.

halostatue 4y ago

s/continuation/hard fork/ Neovim is a hard fork, not a continuation. Vim is still being developed by Bram and other contributors, and has a lot of the same functionality now with different API surfaces. Questionable choices by both development groups (but, IMO, mostly from the initial arrogance of the neovim developers) are increasing the gap to the point where, in a couple of years, I do not expect there to be meaningful compatibility between them. A lot of people don’t like Vimscript, but I personally find the Lua integrations which neovim has to be harder to use because the language isn’t built around the editor, it requires bridging, and there’s a definite impedance mismatch involved. For me, without an equivalent of `gvim`/`MacVim`, neovim is a non-starter. The OS-level integration is important, and none of the various neovim GUIs that exist are nearly as good as the original `gvim` for X or Windows or MacVim for macOS.

israrkhan 4y ago
I find lots of arguments about who was actually more arrogant. But lets look at it from objective perspective. Looking at neovim[1] vs vim[2] contribution Bram is top contributor for vim. 16,211 commit right now. Second top most contributor has 194 commits only. Neovim top contributor has 2285 commits, followed by 21,66 commits for second. It looks to me that neovim is more open to community contribution. Then look at commit graph over period of time. It looks like Neovim is more actively developed. There development activity level around vim also increased in 2016. Perhaps that was the time when bram realized that he need to do more with vim, to compete with neovim. I myself was a longtime vim user, who switched to neovim 2 years ago, and am happy with it. [1] https://github.com/vim/vim/graphs/contributors https://github.com/vim/vim/graphs/contributors [2] https://github.com/vim/vim/graphs/contributors https://github.com/vim/vim/graphs/contributors
kurtreed 4y ago
What did you find arrogant about the neovim developers?
- halostatue 4y ago
  Pretty much everything, including the ongoing lie that Neovim is a "continuation" of Vim. I replied in a different comment (https://news.ycombinator.com/item?id=33922783 https://news.ycombinator.com/item?id=33922783) about the async patches, which is where the whole things started. Because the patches weren’t accepted as is, they hard forked. That requires an incredible amount of arrogance. Neovim is not better than Vim. It is (increasingly) different. They have made different choices, some of which are interesting, some of which are baffling, and most of which are just different, although I consider the removal of GUI support to be about as arrogant as the gemini protocol stuff. There is a pernicious strain of software developer that thinks that they know better on everything and that GUIs are bad. I felt that way in 1992 or so, despite having been exposed in 1990 to X, because it was easy to pick on Windows 3.1 and (then) Mac users. I got over it because there are things which are better, easier, and faster with GUIs than without. Not everything needs a GUI, but if you want people to use your software, leaving it in the terminal is unlikely to be a long-term success strategy.
  - soperj 4y ago
    > Because the patches weren’t accepted as is, they hard forked. They weren't accepted for years, and if you're being honest, they never were going to be accepted. I'm guessing you thought Bram was also arrogant for forking vi?
    - halostatue 4y ago
      You’re right. They weren’t going to be accepted, because they didn’t work the way that Bram thought they should and the people who pushed them would not change them to fit Bram’s goals. As package maintainer myself, if I get a PR/patchset the implements something in a way with which I disagree, I will not accept the changes. If I don’t care enough about the changes, then I probably won’t implement them either. Or I might do so later when I have time. On the history of things, please be more precise. Bram did not fork vi. He worked from the Stevie code, which only ran on the Atari ST, so that he could use it on Amiga. It quickly expanded to other systems (I believe I encountered it after trying other DOS-based vi-like editors). That expansion eventually made it into the relative juggernaut it is today.
shmerl 4y ago
I'm glad for neovim addressing issues that vim ignored for years. The fact that vim picked some of those features is competitive pressure.
sodapopcan 4y ago
Hard agree on lua v. viml. Viml really isn't that bad. I'm certainly not claiming it doesn't have its warts and shouldn't keep improving, but it's a DSL for a text editor... And as you point out, you still need to know a bunch of viml that you have to wrap in Lua calls. At the same time, I haven't actually given vim scripting in Lua a fair shot, so I'd be happy if anyone could shed some light on why they might think it's better.
wirrbel 4y ago
> but, IMO, mostly from the initial arrogance of the neovim developers Vim really was in a sad state prior to the fork which turned out to be a wake up call to Bram it seems.

microsoftdoes 4y ago

“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).