[yanis_t]

I just realised that I'm using Neovim despite there are no nvim-specific plugins in my config (CoC covers most of my needs), and I don't use lua.

Still is feels like Neovim is more stable and faster than the regular Vim somehow. Plus it has much better defaults.

[ilovecaching]

I use default vim, I believe it was a mistake to fracture the ecosystem with plugins that can only be used with neovim. I have also not found any neovim functionality that sells neovim over vim. Vim is fast enough that I have never even thought about it's speed. With term, termdebug, fzf, ripgrep, and ALE with LSPs and Vim's excellent built in support for auto-completion, tag browsing, and cscope, there's really nothing I can't do in another editor I can't do faster in vim and as a bonus I find that I know more about regular expressions than most IDE programmers.

[gpanders]

>I believe it was a mistake to fracture the ecosystem with plugins that can only be used with neovim.

I hate to break this to you, but Vim itself is in the process of converting its runtime files into Vim9script (which is Vim specific), and many new Vim plugins are also being written in Vim9script.

Neovim has always supported "traditional" Vimscript, and has ported all runtime file changes from Vim (think filetype plugins, syntax highlighting, etc.). In fact, we explicitly request that any runtime file changes first go through Vim precisely because we want to keep the two projects aligned. But the more that Vim transitions to Vim9script, the less can be shared between the two projects. So unfortunately the "fracturing of the ecosystem" is not specific to Neovim.

[ilovecaching]

I don't think the onus is on the original project to maintain compatibility with a fork. Neovim made it pretty clear from the beginning that they were going to fracture the ecosystem and now we have colorschemes in Lua that can't be used in vim... say what you will about Emacs, but at least all of their distros can run the same code.

From my perspective as a vim user, neovim has only made my life worse by splitting plugin authors into two camps without any real benefit over what we had in vim. The only good thing about neovim is it caused some nice features to be added to vim, which the neovim authors could have just contributed themselves without trying to fight for control of the ecosystem with Bram. Neovim has really just made things worse for everyone.

[mi_lk]

Probably me but I definitely sense biases in your replies.

Vim ecosystem is 'controlled' by the community not Bram. If Neovim/Lua is not good enough there wouldn't be a fracture in the first place.

The fact that Bram saw the success of Lua with Neovim but insisted on inventing Vim9Script speaks for itself. Yet you somehow manage to blame everything on Neovim.

[earthling8118]

No, that's just not how it works. The original project came back to fracture the ecosystem in response to the fork that did not do so.

[throwawaysalome]

the more Vim transitions to Vim9script, the less ... "fracturing of the ecosystem" [can be attributed to] Neovim.

I see what you did there.

[worksonmine]

I never looked at neovim until Vim9Script. Such a strange choice to invent and maintain a language when that energy can be put to fixing bugs or adding features. He's done amazing work maintaining vim for so long but I don't enjoy the not-invented-here mentality. It adds unnecessary complexity and potential security issues to the codebase with no real benefit.

It's his project he can do whatever he wants, but I'm planning on using this tool for the rest of my career so I went with the fork. Moving my config to XDG_CONFIG_HOME was a welcome side-effect.