5 ms·

> because they believe it splits the Vim community and takes people power away from Vim development I don't understand this point, and I tried to parse it and

> because they believe it splits the Vim community and takes people power away from Vim development I don't understand this point, and I tried to parse it and still don't. (I understand that you are just relaying it). If vim maintainers don't want neovim to exist, they should have accepted the merges earlier. If they disagree with the merges (which I think they did), then that power doesn't belong in Vim anyways. edit: this reminds me of this conversation from years ago https://news.ycombinator.com/item?id=14245705 https://news.ycombinator.com/item?id=14245705 Check DSMan195276's comments. And finally before I derail, I want to bring stuff back to the focus: RIP Braam.

coldtea 3y ago
>I don't understand this point, and I tried to parse it and still don't. (...) If vim maintainers don't want neovim to exist, they should have accepted the merges earlier. If they disagree with the merges (which I think they did), then that power doesn't belong in Vim anyways It's a very simple point to understand: whether the merges are good or not, the presence of a fork still "splits the Vim community and takes people power away from Vim development". And if they're bad (which is the way they see it), they do it for no good reason too. That's regardless of people "having the right to fork". Yes they do. But also yes, if they exercize that right, they do split a community and divert interest from a project to 2 projects.
- falcolas 3y ago
  What splits it more, IMO, is that neovim went in a non-compatible direction with many of their design choices. They have good arguments for doing so, but it still means that writing community plugins that can work with either version of vim is inherently harder.
  - coldtea 3y ago
    I guess if they haven't gotten in a non-compatible direction, then they wouldn't have made enough change to guarantee a fork.
- shanusmagnus 3y ago
  I guess you're right, the logic you describe is simple, but I submit that there's a more fundamental logic: If the folks who split away pull people out of the original community, it means there was demand for the things that prompted the split in the first place. If Neovim had nothing to offer vs vanilla Vim, nobody would have followed them. This seems like efficient exploration of an idea space, to me, and something to be celebrated.
- LexiMax 3y ago
  > That's regardless of people "having the right to fork". Yes they do. But also yes, if they exercize that right, they do split a community and divert interest from a project to 2 projects. You're not dividing the same-sized pie. The alternative to a fork is a single project with fewer contributors. The alternative to two communities is a single community that's not as large as the two would've been, with a good chunk of those remaining having unfulfilled wishes or unheard complaints. The alternative to Vim as it is today is very likely Vim without a a few of its new features and improvements that came with Vim 8 and 9. Forks are good.
  - coldtea 3y ago
    >You're not dividing the same-sized pie. We do. Neither vim-or-vim-fork editor users nor vim-or-vim-fork-potential-devs are going to see any significant jump in population from the presense of neovim. People who are new to vim-style-editors and go to neovim are mainly people who would have gone to vim if neovim didn't exist. And from people contributing to vim via themes, plugins, etc., some have taken their talents to neovim, which would have stayed with vim if neovim didn't exist. >Forks are good Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad.
    - nequo 3y ago
      You are stating these things as though they were established facts. But they seem to be opinions. Or do you have data to back them up? > People who are new to vim-style-editors and go to neovim are mainly people who would have gone to vim if neovim didn't exist. It seems reasonable to assume that a lot of new people would not pick up either Vim or Neovim without LSP integration and Tree-sitter. Vim has adopted a lot of the early features of Neovim and now Vim9 also has things like virtual text for rendering LSP diagnostics in the buffer[1] and there is a Vim9 LSP plugin too. But it does not at all seem likely that Vim would have these were it not for the push from Neovim. Besides, it looks like Vim still does not have mature support for Tree-sitter.[2] > Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad. There are many famous forks from the past 30 years that hardly anybody calls bad. Some examples: Net/Free/OpenBSD, GNU/XEmacs, Open/LibreSSL. These projects allowed people with different goals or values to carry on in their own directions, while also motivating each other to pick up development pace. They have often also shared code with each other. [1] Which looks like this: https://sr.ht/%7Ewhynothugo/lsp_lines.nvim/ https://sr.ht/%7Ewhynothugo/lsp_lines.nvim/ [2] One experimental plugin I came across: https://github.com/mattn/vim-treesitter https://github.com/mattn/vim-treesitter

coldtea 3y ago

>I don't understand this point, and I tried to parse it and still don't. (...) If vim maintainers don't want neovim to exist, they should have accepted the merges earlier. If they disagree with the merges (which I think they did), then that power doesn't belong in Vim anyways It's a very simple point to understand: whether the merges are good or not, the presence of a fork still "splits the Vim community and takes people power away from Vim development". And if they're bad (which is the way they see it), they do it for no good reason too. That's regardless of people "having the right to fork". Yes they do. But also yes, if they exercize that right, they do split a community and divert interest from a project to 2 projects.

falcolas 3y ago
What splits it more, IMO, is that neovim went in a non-compatible direction with many of their design choices. They have good arguments for doing so, but it still means that writing community plugins that can work with either version of vim is inherently harder.
- coldtea 3y ago
  I guess if they haven't gotten in a non-compatible direction, then they wouldn't have made enough change to guarantee a fork.
shanusmagnus 3y ago
I guess you're right, the logic you describe is simple, but I submit that there's a more fundamental logic: If the folks who split away pull people out of the original community, it means there was demand for the things that prompted the split in the first place. If Neovim had nothing to offer vs vanilla Vim, nobody would have followed them. This seems like efficient exploration of an idea space, to me, and something to be celebrated.
LexiMax 3y ago
> That's regardless of people "having the right to fork". Yes they do. But also yes, if they exercize that right, they do split a community and divert interest from a project to 2 projects. You're not dividing the same-sized pie. The alternative to a fork is a single project with fewer contributors. The alternative to two communities is a single community that's not as large as the two would've been, with a good chunk of those remaining having unfulfilled wishes or unheard complaints. The alternative to Vim as it is today is very likely Vim without a a few of its new features and improvements that came with Vim 8 and 9. Forks are good.
- coldtea 3y ago
  >You're not dividing the same-sized pie. We do. Neither vim-or-vim-fork editor users nor vim-or-vim-fork-potential-devs are going to see any significant jump in population from the presense of neovim. People who are new to vim-style-editors and go to neovim are mainly people who would have gone to vim if neovim didn't exist. And from people contributing to vim via themes, plugins, etc., some have taken their talents to neovim, which would have stayed with vim if neovim didn't exist. >Forks are good Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad.
  - nequo 3y ago
    You are stating these things as though they were established facts. But they seem to be opinions. Or do you have data to back them up? > People who are new to vim-style-editors and go to neovim are mainly people who would have gone to vim if neovim didn't exist. It seems reasonable to assume that a lot of new people would not pick up either Vim or Neovim without LSP integration and Tree-sitter. Vim has adopted a lot of the early features of Neovim and now Vim9 also has things like virtual text for rendering LSP diagnostics in the buffer[1] and there is a Vim9 LSP plugin too. But it does not at all seem likely that Vim would have these were it not for the push from Neovim. Besides, it looks like Vim still does not have mature support for Tree-sitter.[2] > Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad. There are many famous forks from the past 30 years that hardly anybody calls bad. Some examples: Net/Free/OpenBSD, GNU/XEmacs, Open/LibreSSL. These projects allowed people with different goals or values to carry on in their own directions, while also motivating each other to pick up development pace. They have often also shared code with each other. [1] Which looks like this: https://sr.ht/%7Ewhynothugo/lsp_lines.nvim/ https://sr.ht/%7Ewhynothugo/lsp_lines.nvim/ [2] One experimental plugin I came across: https://github.com/mattn/vim-treesitter https://github.com/mattn/vim-treesitter