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.

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

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

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

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

  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.

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.

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.

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.

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.

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.

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

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

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

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?

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

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