[QwenGlazer9000]

All the other comments in this thread talk about emacs instability when that hasn't been the case for me. I'm on doom emacs, update once in a while, and everything mostly just works other than some color scheme weirdness I had to fix.

I used to be on neovim, and that ecosystem compared to emacs feels like this image: https://i.imgflip.com/2pg2s7.jpg

Some of it is the maintainer shielding us from the breaking changes, but I also think the ecosystem is more slow moving than other editors which helps. The editor is older than most devs after all.

[arikrahman]

I find that Emacs is actually the first mover on prime technologies. Just look at gptel and org-mode. Nothing else really even comes close. The reason some odd names exist like yank and kill or kill chain is because Emacs was the first and didn't have anything else to use as reference.

[imglorp]

That's right teco/emacs pre-dates xerox gypsy, which coined cut/copy/paste.

[rpdillon]

Kill chain is a military term relating to the sequence of events that lead up to the actual attack.

You're probably thinking of kill ring, which I always thought was a neat term.

[wglb]

It's also used in security defense, where there is a search for how to stop the many steps of attack.

[db48x]

Technically Kill and Yank came from TECO, which is an entirely different visual editor that predates Emacs.

[royal__]

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)

[iLemming]

> 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.

[royal__]

That all makes sense. I wasn't trying to attack Emacs or defend Neovim, for the record. I liked Emacs and didn't have any problems with it (except some window jankiness). I was mostly just curious about the ecosystem.

The big reason I switched is because a lot of the big features of Emacs (org mode, magit, "living" in Emacs, advanced text manipulation, the extreme extensibility of the software) were things that sound really amazing on paper, but in practice I just don't really need/use/care about, and that's just my preferences. But once again, Emacs is cool and I totally respect what it can do.

[iLemming]

Missing the point - it's not about "attacking/defending" - Emacs and Vim just can't be compared categorically, the core of their design is about two dissimilar, unrelated concepts. Vim's augmentation of modality is absolutely brilliant, beautiful model, enormously practical idea. Emacs rooted in another incredible, powerful idea - practical symbolic notation for lambda calculus. Comparing them plainly from their "text editor" aspect is wrong - it creates wrong perception of they are about.

It's almost invariably about the trade-offs, without knowing what they are and how to navigate them would remain a highly debatable topic.

You have fixated on a single (albeit voluminous) aspect of things to make a choice. But there are dozens of other things we can drop there and steer away from Emacs with wrong conclusions, e.g. Emacs has mail client capabilities, and for anyone unfamiliar with Lisp, it might be obvious - more specialized email apps would look far more capable. But for an experienced Lisper, no specialized app would ever suffice. Particularly because Lisp allows them to adapt things with extreme precision, specifically for their use cases.

> The big reason I switched

You have switched (as it seems) without even understanding what it was about. It's not about Org, Magit, or any other "features" of Emacs. The main idea is and always was the Lisp interpreter. For someone like me (staunch Lisper) Magit is not some "packaged", ready-to-use piece of software, it's a set of libraries I can use. I can easily incorporate just about any Magit function into my workflow directly. I don't have to submit patches, I don't have to ask anyone's permission, I don't have to guess - the source code is given, I don't even have to save my experiments anywhere - I can just start typing Elisp code in my scratch buffer and eval things in place. Similarly - I use Org-mode for a bunch of things that may sound absolutely unrelated - I consume HN, Reddit, Jira, GitHub, Slack and other content in org-mode derived buffers. Why? Again, because of bunch of APIs, functions and commands that Org provides. I can for example easily retrieve any HN thread and extract all the URLs people posted in comments, and inspect each in-place - takes me a keystroke. Or I can send the text to an LLM - without ever copying and pasting, without context switching, without losing focus. No other [popular] piece of software ever granted me such enormous power and liberation.

I am absolutely so grateful to my younger self for forcing me to grok Emacs and Lisp, and I will never understand the sentiment and the "reasoning" of people moving away from it (after being exposed to its absolute supremacy over plain text). Realistically, there's never switching away from Emacs for me, that, unless a better Lisp engine emerges at some point. And btw. I am a die-hard Vimmer. I use vim motions everywhere - system wide. They permeate my editors/IDEs, web browsers, terminals, and yes, even Emacs. And I use Neovim as well - it works well when I need to reach for it - like I said: it's not a comparison.

[JadeNB]

> 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.

[aktau]

I think Neovim itself has been stabilizing quite a bit in terms of upgrade breakage.

A common reason for breakage is/was:

  - Neovim changes some API (deprecating, ...).
  - User upgrades Neovim and theres some incompability, OR user upgrade plugin and that plugin assumes a much newer version of Neovim. (I've often seen Neovim plugins "mandate" either the latest stable Neovim or even HEAD).

But:

  1. Neovim has been including some popular plugins (or at least their functionality domain) in the past few years. This obviates the need for plugin-for-$THING, and reduces breakage.
  2. ISTM that the pace of (new) plugin development in the Neovim-sphere has slowed down.

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.

[QwenGlazer9000]

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.

[lycopodiopsida]

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.

[maleldil]

> 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.

[rjzzleep]

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.

[maleldil]

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.

[QwenGlazer9000]

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.

[zelphirkalt]

To be fair, there are also tons of ways to manage packages in Emacs.

[sph]

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.

[maleldil]

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.

[gsinclair]

That’s a serious misreading of the NeoVim ecosystem, and I’d bet good money against your predictions coming true.

[QwenGlazer9000]

I've been seeing improvements lately other than the treesitter debacle, but this was literally the case 1 year ago.

[Barrin92]

>wrong with the Neovim ecosystem?

It's like a willful exercise in ignoring systems thinking. With Emacs every package tends to be designed with Emacs itself in mind, packages like consult, vertico, marginalia etc all built on Emacs' facilities improving not just the package itself but the overall experience of using Emacs, intentionally so.

The Neovim ecosystem is a bit like a dozen architects each designing a room in a house with total disregard for the layout of the house. A very common experience I had, and I never even used many plugins, was that when something was updated often something else would break. An update in the completion engine would cause some weird quirk with the lsp backend, etc.

[bogomog]

20 or 25 years ago it almost never crashed. Now I might see a crash or freeze once a week or so. And slowdowns several times a day. Of course I'm running more modes now in a more customized environment. Hopefully this new version with more in it will improve the situation.

[Alien1Being]

I use both Emacs ( have used it for decades ) and began using Neovim recently.

Neovim seems fairly reasonable. Using the LazyVim distribution of Neovim and it works quite well for my purposes.

[QwenGlazer9000]

Distros help a lot shielding you from the churn, but lazyvim is maintained by folke who I hear loves breaking changes. Back when I used lazyvim I remember people complaining that he swapped out some major component randomly, I think it was auto complete.

Respect where it's due to folke, he's been pushing the neovim ecosystem forward incredibly fast. The bleeding edge just ain't everyone's style though.

[quertyrecord74]

Use borg package. You'll get rock solid emacs. Worth the effort.

[sph]

Link: https://github.com/emacscollective/borg

Seems worth a look, simply because it’s from the magit author.

[cvdub]

Don’t think stuff like borg is necessary now that Emacs has built in support for installing packages from git repos (use-package :vc)

[shevy-java]

The irony is that the vim camp can use just the same "argument" here about emacs. So that is a weird comparison to want to make here.

> The editor is older than most devs after all.

Well, being old does not automatically mean better. Peak human physical performance typically happens, with some exceptions (Justin Gatlin, if we ignore the use of enhancement drugs) in younger years; see Usain Bolt's fastest time achieved when he was young (23 years, in 2009). For mental tasks it is not so limited, but for physical peaks it is often in the younger years. For some software projects it also is the case that older age means more code, which in turn automatically mean smore bugs, all other things being equal. I am not necessarily questioning as to whether emacs has more bugs; my point is that the comparison/analogy does not work as means of quality assessment.

[sph]

The evidence of younger code being better than old one doesn’t pass the smell test, and it’s hard to prove in a nascent field of technology where the oldest piece of software in continuous use has barely reached middle age.

You just cannot compare software robustness to human lifespan. Does software need 3 years at the bare minimum to be self-sufficient? Does it become argumentative and crashes a lot after 13-14 years?

[DonHopkins]

It's as wrong to anthroporphize Emacs as it is Larry Ellison.

[weinzierl]

If you look at the output of mathematicians and their biggest discoveries it suggests that it is similarly limited for mental tasks.

[kensai]

Probably this category of mental tasks. For politicians it's the other way around. Prolly you need to have some 'elder statesman' skills as well as wisdom to achieve greatness. Deng Xiaoping (https://en.wikipedia.org/wiki/Deng_Xiaoping) started changing China at the venerable age of 70+ moving forward until his death almost two decades later.

Do not underestimate wisdom as a cognitive skill, even if in today's world we tend to discredit it because of agism.

[zelphirkalt]

To bring up politicians, in a discussion about mental peak performances ... yeah, no, it's funny.