Can you explain more what's wrong with the Neovim ecosystem? I just switched from Doom Emacs to Neovim and my impression of Neovim has been much better. (I get that Emacs has a much more powerful backbone, I just realized that I didn't really need that power; I just want a good text editor)
> what's wrong with the Neovim ecosystem
Nothing's wrong with it. It's just incomparable categorically. Just like you can't really equate a photo-editor and the web-browser. Sure, there's a way to do photo editing in the browser, still will be weird to compare them.
> Neovim has been much better
In what sense? Emacs is a Lisp interpreter with a text editor embedded in it - one can fully emulate Neovim features in it, the opposite is hardly possible - you can bolt Lisp interpreter on top of Neovim, but it won't be the same.
> I just want a good text editor
Is that implying Emacs doesn't have "a good one"? You probably just have not discovered some mind-blowing features of the editor. It is hands down the best-known machine ever designed to deal with plain text, nothing even comes close. Indirect buffers alone are such a brilliant idea, I have zero clue how people ever exposed to that power would willingly abandon it. I get it though, building a text-manipulating theater orchestrated by Lisp is not for everyone. Unfortunately, most newcomers get attracted to Emacs hearing "how powerful an editor it is", without ever learning what exactly makes it as such.
> In what sense? Emacs is a Lisp interpreter with a text editor embedded in it - one can fully emulate Neovim features in it, the opposite is hardly possible - you can bolt Lisp interpreter on top of Neovim, but it won't be the same.
Unless this is specifically what you want to do with Neovim, in which case you'll probably just use Emacs anyway, Neovim's inability to do this is probably not a strike against it. As royal__ says (https://news.ycombinator.com/item?id=48537120), they are just interested in a good text editor, not in raw computational power.
I think Neovim itself has been stabilizing quite a bit in terms of upgrade breakage.
A common reason for breakage is/was:
But:
The latest example of #1 is vim.pack, which is a plugin manager similar to vim-plug, mini.deps (vim.pack is based on mini.deps), lazy et cetera.
I can remember removing vim-commentary (from tpope) a while ago because Neovim included something like it in the main distribution. Granted, that specific plugin never broke because it uses the stable viml API.
Yeah the lack of basic features in core meant core functionality was forced to use plugins with varying levels of documentation and commitments to stability (in some cases sending breaking changes before the supported neovim version even reached the arch repos). I'm glad to see neovim is improving in that aspect.
I think a big difference is that in the end emacs often makes a call and adopts one of the very popular packages to the core - eglot, modus-themes, use-package - there are certainly more, and more will come. It may not make everyone happy, but is sets the baseline - e.g., I am using eglot as package manager, but I wrap it into use-package commands for compatibility reasons.
No such thing exist in neovim (or at least in times when I was using it), so that churn never ends. Also I find, that neovim ecosystem is concentrated on one (very productive) developer in an unhealthy manner - folke often takes time off and half the packages one uses stands still.
But in the end, while I like neovim, I also find that emacs ecosystem has better ideas - which-key, embark do not stop to amuse me (I will not comment on whether it is a good thing for a text editor). I also do not like lua and actively dislike the experience of debugging and configuring neovim with it (maybe less of an issue with LLM these days).
In my experience, running in a terminal absolutely adds a bunch of rendering/performance issues and all kind of surprising failures with hotkeys.
> emacs often makes a call and adopts one of the very popular packages to the core
> No such thing exist in neovim
neovim has been doing that too. Plugin manager (vim.pack), treesitter stuff, LSP management, completion, comments, etc.
> which-key
neovim also has this.
> neovim ecosystem is concentrated on one (very productive) developer in an unhealthy manner
folke has nice stuff, but I find a lot of it is largely unnecessary and bloated. The only thing I use is his which-key, and there are alternatives, such as mini.clue.
LSPs keep getting reimplemented, package managers keep getting reimplemented. It's a bit like the react version of text editors.
I used it more than I use emacs, but I agree with the assessment of doom emacs vs neovim.
To be fair, there are also tons of ways to manage packages in Emacs.
neovim core has most of what you need for LSPs. The only thing missing is server-specific configuration (e.g. binary name, flags), which you can copy from nvim-lspconfig or write yourself. There's also a native package manager in the core.
It literally wasn't the case until relatively recently. It's an improvement in stability for the future, but the fact that before we had plug, then lazy, then finally we now have a built in one doesn't support the case necessarily the neovim ecosystem has a lot of churn.
I hope with these new built in alternatives that will change.
Neovim suffers from the Javascript kids mode of development. Constant change, constant churn, the mirage of stability always behind the corner, you always require third-party packages for functionality that should be core, completely erasing the Lindy effect of vim proper.
It’s a bit sad Neovim has stolen the thunder from the original work of Moolenaar & co. My guess is that neovim will splinter itself down the line further again once lua stops being attractive, while vim & Emacs will keep chugging along for another half century.
That’s a serious misreading of the NeoVim ecosystem, and I’d bet good money against your predictions coming true.
I've been seeing improvements lately other than the treesitter debacle, but this was literally the case 1 year ago.
When did you last look at the neovim ecosystem? Because what you describe is the opposite of what's happened recently. The core has been getting more stable over time, with fewer breakages, and more essential functionality has been added, such as LSP support, completion, and a package manager, with plans to add more.