Disagreement insofar as the direction of vim. Neovim choosing to go there on way on functionality they wanted to implement both ultimately enriched vim as some ideas found there way into vim proper and gave the community additional options.
Such splits aren't always handled well and value is lost when good ideas aren't merged back because of personal reasons and when contributors stop contributing because they are turned off by the drama. See libav vs ffmpeg.
> 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
>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.
> 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.
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.
Neovim migrated to a more modern style of C and more tightly integrated Lua as its scripting language (instead of conscript). Those are two large potential stumbling blocks for contributors.
From loosely following development over the years, I see names like chrisbra and justinmk who contribute to both projects, but there seem to be many who contribute to neovim but never contributed to vim.
Neovim also seems to have influenced the development of vim: channels, jobs, terminal mode, and issues/PRs on github (instead of mailinglists) felt like shifts in response to neovim.
I think it's also to Bram, justinmk, and other maintainers credit that the two projects contribute back and forth: many vim fixes are merged to neovim and I see big changes get brought back to vim too.
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.
This thought process contains the misconception that non-paying users are the primary currency that sustains a project as opposed to developers even though the former are nearly worthless and the latter vital.
It contains the misconception that without the fork and the ability to create what they want to create that the additional developers who themselves aren't getting paid would magically be reverted to additional free workers for a project they don't run even though they can't do what they want. In reality it is likely to lead to more total developers working on the ecosystem.
It contains the misconception that code created for the fork is worthless for the primary project despite the fact that compatibly licensed code can either directly be used or can be used as a conceptual v1 that can be improved with the benefit of the prior work.
> Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad.
If this were well supported people would probably mention actual projects that had been hurt by forks instead of speaking of hypothetical matters for multiple decades. This is brought to you by the same line of thinking that we all ought to work on one foo where foo is a an application because then and only then would open source compete with the billions of dollars poured into photoshop and the entrenched benefit of OEMs supporting the windows ecosystem with its application ecosystem, broad hardware support, billions of dollars to pay developers, and ability to earn money on shovelware and convince grandma to instead download Linux ISOs.
Just because its commonly expressed doesn't mean there is merit to the argument.
>This thought process contains the misconception that non-paying users are the primary currency that sustains a project as opposed to developers even though the former are nearly worthless and the latter vital.
And yet, projects that fail to get adoption and foster a community rarely go that far, except if they're small hobby projects that can fit on one or two developers scope.
>It contains the misconception that without the fork and the ability to create what they want to create that the additional developers who themselves aren't getting paid would magically be reverted to additional free workers for a project they don't run even though they can't do what they want.
Projects are not just about core developers. They're also about adoption, documentation (webpages, posts, books, articles), plugins, even themes, and configuration bundles. All of those are split in a fork.
And it's not like without NeoVim most of those vi-style-liking people would have gone to a totally different alternative editor. Most of them would have stayed with Vim. Especially when the differences where small to begin with (but enough to fragment compatibility in many areas).
Devs and users (including new devs and users) that would have gravitated towards Vim, now have the addec choice to gravitate towards NeoVim. The amount of people, that, absense of NeoVim, would have gravitated towards something completely different is, I'd say, much smaller.
>If this were well supported people would probably mention actual projects that had been hurt by forks instead of speaking of hypothetical matters for multiple decades
People have mentioned actual projects that have been hurt by forks. XFree86 vs X.org, OpenOffice.org vs LibreOffice, MariaDB vs MySQL, and others. The xBSD fragmentation didn't help either to them losing ground to Linux.
> 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.
Last time I used vim there was still a thriving ecosystem of vanilla-compatible vimscript plugins. And this thread is full of neovim users who continue to use vim for some use cases, like on remote machines. How many vim users do you suppose use neovim for certain tasks? :)
> Well, the prevalent wisdom of 30+ years of FOSS has been that they're mostly bad.
My experience has given me the exact opposite impression. Forking may not always mutually benefit both projects, but the end result at worst occupies the time of a few disgruntled maintainers who would have likely stopped contributing anyway, and at best delivers real value for users by being responsive to their needs and desires.
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.
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.
That feels a bit like criticizing all the c-style programming languages for splitting the C community... Which is an analogy I rather like, as it suggest Vim has become so foundational that its legacy goes beyond the direct users of it. I've certainly found that to be so, as in addition to using vim itself, I also use its key bindings wherever I can.
Is there any disagreement on who is going to support Vim moving forward?
I can see the fork maintainers going into a power struggle if the future is unclear. Maybe some will even write fluffy pieces on how much they loved Bram to gather support...
