9 ms·

Although I am currently tip-toeing on NeoVim, I still feel this is a horrible break-up. Yes, Open Source simply allows you to branch whenever you're unhappy wi

Although I am currently tip-toeing on NeoVim, I still feel this is a horrible break-up. Yes, Open Source simply allows you to branch whenever you're unhappy with the original but this comes at a cost for the community. The cost of having two diverging programs to deal with. In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own. Not bad reasons in itself, but does it weigh against the tremendous cost for the community of the split? Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? Couldn't they not convince Bram Moolenaar of proposed changes, and if not, doesn't this have a good reason. I hate NeoVim for the reason they've split, even though I understand it might become even better than Vim in the long run. You need better reasons to fork and divide an ecosystem.

otikik 4y ago
It could be also argued that if Vim wanted to keep the community together they could have just deprecated vimscript and adopted Lua. Of course I am stretching things a little, I know. I personally think Neovim's reasons for a fork are valid. They wanted some parts, not others, and they were willing to pull the work. So a fork is made. That is all ok. If my memory serves both projects have interchanged patches and improvements in both directions, so everyone has benefitted in some ways. The community (communities) will live on.
Tyr42 4y ago
I mean all Bram had to do was accept the async patches instead of ignoring them. Then neovim wouldn't have got off the ground. Once they started building, they wanted to "cut the cruft" and just went from there
- mempko 4y ago
  Ignore them? Far from it. Brahm provided a lot of feedback. The authors got lazy abd forked instead of dealing with criticism of their design.
  - weakfish 4y ago
    Forking is hardly easier
    - KerrAvon 4y ago
      Easier on the ego
capableweb 4y ago
> In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own. > Couldn't they not convince Bram Moolenaar of proposed changes I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaar didn't want to merge it, for one or another reason. That cascaded to a bunch of other reasons over time, like adding Lua support and trying to rely less on Vimscript. But that's how I remember it being started at least, but I could remember it wrong.
- aidos 4y ago
  Correct. HN threads from the time: https://news.ycombinator.com/item?id=7057051 https://news.ycombinator.com/item?id=7057051 https://news.ycombinator.com/item?id=7278214 https://news.ycombinator.com/item?id=7278214
- dvogel 4y ago
  This has entered the popular lore but I think it is easily proved false. The thread in question: https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2mokJ https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2... My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine): You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.* The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said: Bram, I happy to see there is still some hope for this patch getting merged. Then shortly afterward the other author gave Bram an ultimatum: Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up. If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim. Considering where the patch started, iterative feedback seems appropriate. Bram replied (in part): It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested. The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history. As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3FwAJ https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.
kzrdude 4y ago
Neovim has already been very productive by giving Vim some good competition and in so doing having better features come out in Vim. To me it doesn't make sense to 'hate' neovim for wanting to develop features that they tried to have in Vim but couldn't due to the main developer stalling it.
- calvinmorrison 4y ago
  To me, vim has never been emacs. I run two plugins, vdebug and MRU (most recently used list... super useful). Everything else is out of the box. I like where neovim is going, I think it's great, but vim is fine for me.
bobbylarrybobby 4y ago
I think Neovim had a whole bunch of other reasons to split. I'm pretty sure that Neovim's server mode, which allows it to be used with other editor frontends, is simply not present in vim. For me this is the whole reason to use Neovim. But I think it also natively supports tree sitter and/or LSPs, which really improve the coding experience. Anyway iirc Neovim wanted these features integrated into Vim itself and only started a separate project when it became clear that that wasn't going to happen. My understanding was that at the time Bram was hostile to lots of the changes that people wanted integrated. You can read some of the discussion [here](https://news.ycombinator.com/item?id=14245705 https://news.ycombinator.com/item?id=14245705) and [here](https://news.ycombinator.com/item?id=7287668 https://news.ycombinator.com/item?id=7287668)
- deadbunny 4y ago
  And when Bram did finally add async support rather than take the neovim work and us that he did it in a specifically non compatible way. I don't know the ins and outs but as an observer that does come across as a little petty.
  - kzrdude 4y ago
    We're used to open projects but Bram's seems to be that he wants to be in control, he's the main author. So Vim is then open source but not a completely open project.
    - margarina72 4y ago
      open source mean the source is a open (and few other points described in [0]). Vim licence [1] is GPL compatible. It is fully open source. Open source does not mean the maintainer is under the obligation to add features, or integrate PRs. [0]: https://opensource.org/osd https://opensource.org/osd [1]: https://www.gnu.org/licenses/vim-license.txt https://www.gnu.org/licenses/vim-license.txt
      - kelnos 4y ago
teilo 4y ago
Vim was stagnant until Neovim became a threat. And it was never about Lua. It was about the need for async. Bram ignored the community, and so the community responded, and made something better.
akerl_ 4y ago
Nobody needs to justify forking a project to other people.
fatbird 4y ago
async and embedded terminal were the original features neovim was created to realize; later, lua as the first class plugin language came in. Underlying it all, though, was that vim has a bus factor of 1: Bram. Bram is the sole chokepoint through which all change flows, and thus holds back a lot of community dev. Neovim early on pursued a working model allowing for a larger community of interested devs to contribute, and it's paid off: the originator of neovim has moved on and a new steward has taken over smoothly, and they have around 30 core contributors. So your anger at Neovim is misplaced. They created a modern vim open to many devs, and incidentally rekindled active work on vim, which had been stagnant before. You should be thanking them, even if you don't switch. You have async and terminals in vim because of them.
- cardanome 4y ago
  Stability, backwards compatibility and ubiquity are my reasons for using VIM so I neovim doesn't really offer much for me. Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way? There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.
  - fatbird 4y ago
    The problem, as perceived by the neovim creators, was that vim wasn't moving at all. It wouldn't have taken a bit longer; after their experience, they felt like async just wasn't on Bram's radar, and the maintenance model of vim was hostile to not-Brams. They needed to please Bram to get their patch in, and he spent months saying "fix this. Ok, now fix this. Now fix this." You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch. Stability and backwards compatibility were built into neovim from day one. I used it from the 0.1 days, never had a crash, and all my vim plugins just worked. They put incredible effort into not breaking compatibility with existing vimscript, even as they constructed a new, modern build pipeline and development model, and refactored 30% of the code out. It wasn't until they added features of their own that full compatibility was lost because Bram wasn't interested in porting their work back to vim. This really wasn't "move fast and break things". It was "vim development is stagnant, our only choice is a fork." And now Vim and Neovim are now vastly better pieces of software than Vim 7 was. Forking Vim did wonders for Vim itself.
williamsmj 4y ago
I don't know if the "split" is justified, but "Some people wanted vimscript+lua instead of vimscript" is not an accurate description of the reasons for the existence of the neovim project. The goals and non-goals are stated clearly in the project charter: https://neovim.io/charter/ https://neovim.io/charter/.
xvilka 4y ago
> Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? I think, the situations are incomparable. OpenOffice is effectively dead and should admit that, it's abandonware unlike Vim which is actively developed. Let all flowers blossom. Just remove dead ones from the garden. It's infuriating that OO insists they do something while they don't, best they can do now is to just put redirection to the LO site and move on.
- calvinmorrison 4y ago
  lest us not forget the years of good hardwork of the openoffice patchset, i think it was called Go-OO that was basically a bunch of package maintainers trying to keep OO running. That became the eventual basis for LO.
stonekyx 4y ago
The split of Vim and NeoVim was actually one of the reasons why I chose to switch to Emacs 2 years ago, after sticking with Vim for ~15 years. Vim was great but the script language had always been too hard for me. NeoVim was getting a lot of development, but it was foreseeable that Vim & NeoVim would be completely incompatible someday, and I'd feel bad leaving the original Vim community for something that might eventually replace it. At that point I figured, if I have to switch, let's try something that's more stable and less likely to fork. Then I never looked back.

otikik 4y ago

It could be also argued that if Vim wanted to keep the community together they could have just deprecated vimscript and adopted Lua. Of course I am stretching things a little, I know. I personally think Neovim's reasons for a fork are valid. They wanted some parts, not others, and they were willing to pull the work. So a fork is made. That is all ok. If my memory serves both projects have interchanged patches and improvements in both directions, so everyone has benefitted in some ways. The community (communities) will live on.

Tyr42 4y ago

I mean all Bram had to do was accept the async patches instead of ignoring them. Then neovim wouldn't have got off the ground. Once they started building, they wanted to "cut the cruft" and just went from there

mempko 4y ago
Ignore them? Far from it. Brahm provided a lot of feedback. The authors got lazy abd forked instead of dealing with criticism of their design.
- weakfish 4y ago
  Forking is hardly easier
  - KerrAvon 4y ago
    Easier on the ego

capableweb 4y ago

> In this case, the motivation was simply insufficient. Some people wanted vimscript+lua instead of vimscript. They felt the code was too difficult. They wanted to develop on their own. > Couldn't they not convince Bram Moolenaar of proposed changes I think (but someone correct me if I'm wrong) it started out with one of the persons who started Neovim, tried to get in a patch adding async support in Vim, but Moolenaar didn't want to merge it, for one or another reason. That cascaded to a bunch of other reasons over time, like adding Lua support and trying to rely less on Vimscript. But that's how I remember it being started at least, but I could remember it wrong.

aidos 4y ago
Correct. HN threads from the time: https://news.ycombinator.com/item?id=7057051 https://news.ycombinator.com/item?id=7057051 https://news.ycombinator.com/item?id=7278214 https://news.ycombinator.com/item?id=7278214
dvogel 4y ago
This has entered the popular lore but I think it is easily proved false. The thread in question: https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2mokJ https://groups.google.com/g/vim_dev/c/-4pqDJfHCsM/m/LSFNhqs2... My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine): You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.* The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said: Bram, I happy to see there is still some hope for this patch getting merged. Then shortly afterward the other author gave Bram an ultimatum: Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up. If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim. Considering where the patch started, iterative feedback seems appropriate. Bram replied (in part): It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested. The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history. As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3FwAJ https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.

kzrdude 4y ago

Neovim has already been very productive by giving Vim some good competition and in so doing having better features come out in Vim. To me it doesn't make sense to 'hate' neovim for wanting to develop features that they tried to have in Vim but couldn't due to the main developer stalling it.

calvinmorrison 4y ago
To me, vim has never been emacs. I run two plugins, vdebug and MRU (most recently used list... super useful). Everything else is out of the box. I like where neovim is going, I think it's great, but vim is fine for me.

bobbylarrybobby 4y ago

I think Neovim had a whole bunch of other reasons to split. I'm pretty sure that Neovim's server mode, which allows it to be used with other editor frontends, is simply not present in vim. For me this is the whole reason to use Neovim. But I think it also natively supports tree sitter and/or LSPs, which really improve the coding experience. Anyway iirc Neovim wanted these features integrated into Vim itself and only started a separate project when it became clear that that wasn't going to happen. My understanding was that at the time Bram was hostile to lots of the changes that people wanted integrated. You can read some of the discussion [here](https://news.ycombinator.com/item?id=14245705 https://news.ycombinator.com/item?id=14245705) and [here](https://news.ycombinator.com/item?id=7287668 https://news.ycombinator.com/item?id=7287668)

deadbunny 4y ago
And when Bram did finally add async support rather than take the neovim work and us that he did it in a specifically non compatible way. I don't know the ins and outs but as an observer that does come across as a little petty.
- kzrdude 4y ago
  We're used to open projects but Bram's seems to be that he wants to be in control, he's the main author. So Vim is then open source but not a completely open project.
  - margarina72 4y ago
    open source mean the source is a open (and few other points described in [0]). Vim licence [1] is GPL compatible. It is fully open source. Open source does not mean the maintainer is under the obligation to add features, or integrate PRs. [0]: https://opensource.org/osd https://opensource.org/osd [1]: https://www.gnu.org/licenses/vim-license.txt https://www.gnu.org/licenses/vim-license.txt
    - kelnos 4y ago

teilo 4y ago

Vim was stagnant until Neovim became a threat. And it was never about Lua. It was about the need for async. Bram ignored the community, and so the community responded, and made something better.

akerl_ 4y ago

Nobody needs to justify forking a project to other people.

fatbird 4y ago

async and embedded terminal were the original features neovim was created to realize; later, lua as the first class plugin language came in. Underlying it all, though, was that vim has a bus factor of 1: Bram. Bram is the sole chokepoint through which all change flows, and thus holds back a lot of community dev. Neovim early on pursued a working model allowing for a larger community of interested devs to contribute, and it's paid off: the originator of neovim has moved on and a new steward has taken over smoothly, and they have around 30 core contributors. So your anger at Neovim is misplaced. They created a modern vim open to many devs, and incidentally rekindled active work on vim, which had been stagnant before. You should be thanking them, even if you don't switch. You have async and terminals in vim because of them.

cardanome 4y ago
Stability, backwards compatibility and ubiquity are my reasons for using VIM so I neovim doesn't really offer much for me. Yeah, I took a bit longer for async to land in VIM proper but how is that a problem? Isn't is good that Bram put his foot down and insisted to do it right-way instead of the fast way? There is already enough "move fast and break things" software out there. I am happy for neovim and some innovations are interesting but for me the disadvantages of less stability are not worth it. I don't really see a need to increase the "bus factor". VIM is not a business, it can afford to move slowly but purposefully.
- fatbird 4y ago
  The problem, as perceived by the neovim creators, was that vim wasn't moving at all. It wouldn't have taken a bit longer; after their experience, they felt like async just wasn't on Bram's radar, and the maintenance model of vim was hostile to not-Brams. They needed to please Bram to get their patch in, and he spent months saying "fix this. Ok, now fix this. Now fix this." You can tell from Thiago's last message that he's come to believe they'll never get their patch accepted because there'll always be one more thing to fix because Bram doesn't want their patch. Stability and backwards compatibility were built into neovim from day one. I used it from the 0.1 days, never had a crash, and all my vim plugins just worked. They put incredible effort into not breaking compatibility with existing vimscript, even as they constructed a new, modern build pipeline and development model, and refactored 30% of the code out. It wasn't until they added features of their own that full compatibility was lost because Bram wasn't interested in porting their work back to vim. This really wasn't "move fast and break things". It was "vim development is stagnant, our only choice is a fork." And now Vim and Neovim are now vastly better pieces of software than Vim 7 was. Forking Vim did wonders for Vim itself.

williamsmj 4y ago

I don't know if the "split" is justified, but "Some people wanted vimscript+lua instead of vimscript" is not an accurate description of the reasons for the existence of the neovim project. The goals and non-goals are stated clearly in the project charter: https://neovim.io/charter/ https://neovim.io/charter/.

xvilka 4y ago

> Isn't a split only justified in situation like OpenOffice/LibreOffice when there is no other choice? I think, the situations are incomparable. OpenOffice is effectively dead and should admit that, it's abandonware unlike Vim which is actively developed. Let all flowers blossom. Just remove dead ones from the garden. It's infuriating that OO insists they do something while they don't, best they can do now is to just put redirection to the LO site and move on.

calvinmorrison 4y ago
lest us not forget the years of good hardwork of the openoffice patchset, i think it was called Go-OO that was basically a bunch of package maintainers trying to keep OO running. That became the eventual basis for LO.

stonekyx 4y ago

The split of Vim and NeoVim was actually one of the reasons why I chose to switch to Emacs 2 years ago, after sticking with Vim for ~15 years. Vim was great but the script language had always been too hard for me. NeoVim was getting a lot of development, but it was foreseeable that Vim & NeoVim would be completely incompatible someday, and I'd feel bad leaving the original Vim community for something that might eventually replace it. At that point I figured, if I have to switch, let's try something that's more stable and less likely to fork. Then I never looked back.