Comment by iLemming
8 hours ago
50 years old and feels more modern than any of the crap folks try to sell you "as the editor of the future". Emacs is the true editor of the past, present and distant future.
Modal editing was supposed to pull users away - Evil mode made vimming better. LSPs were supposed to kill it - only made it better. Electron-based crap was supposed to make terminal-native editors look ancient with a built-in terminal, extensions, and a polished UI. Emacs got vterm, eat, and ghostel. GitKraken-like GUIs were supposed to make the git CLI unnecessary. Magit is widely considered better than any git client that exists, GUI or not. Tree-sitter was supposed to require a "real" language server architecture to get accurate parsing. Emacs 29 absorbed it natively, and font-lock, indentation, and structural navigation across major modes got noticeably better. Obsidian and Notion keep trying to overcome it - Org-mode just keeps getting better. AI was supposed to make it outdated - only enhanced it.
For half a century, humanity has been searching for an Emacs-killer. All the while, Emacs has been a killer app all along.
According to `git blame` the oldest surviving code in GNU emacs is:
being unchanged since 1986-09-12.
(It is said the Stallman maybe have kept some of Gosling's older code but I haven't gone back that far.)
I like it infinitely more than anything, but it also still feels like a comparably slow, crufty pos that will probably die because of how anti-AI half the core community is. Regardless of how good magit is, it's slow.
I also can't understand how people like eca and agent-shell so much unless they've never actually used any decent harness. Neither seems to really fit with emacs. Acp is the exact opposite of extensible, and eca isn't really extensible either.
Had the last ten years of emacs development never happened, I suspect emacs would be just as used. So no, I don't think the anti-AI stance would extinguish the compelling repl-as-editor proposition that emacs does so well. I wouldn't put too much stock in the agent-shell business. It's got junior dev written all over it, and they're the most vocal.
[dead]
Agreed with all of this! To date, agent-shell.el is my favorite AI coding experience.
eca and gptel remain my main "bread-n-butter" atm.
I'm using claude-code.el. What am I missing? (Aside from integration with other models of course).
I have used gptel a while ago which was great for completion-like workflow, but abandoned when I moved to more agentic stuff.
3 replies →
Yes, Emacs was designed almost perfectly 50 years ago to integrate with modern LLMs.
We just got lucky. Emacs Lisp, unlike most other Lisps that are data-oriented is particularly text-oriented. If instead of LLMs we've gotten LGMs (Large Graphics Models), Emacs wouldn't have time to catch up and keep the pace with other graphics-oriented IGEs (that would've replaced IDEs)
Luckily (for us), Emacs is the king of text-processing and text manipulation.
They had ELIZA and then the Emacs doctor, the rest is just scale.
[flagged]
I will say in regards to the electron editors, wrangling emacs frames and windows can range from a chore to painful. That is one area we can still improve on!
I grokked display-buffer-alist and never had any problems since. With any other editor or IDE (and I used more than a few), it never occurred to me to even want to do anything complex with window placement. There are things I would love to see getting improved in Emacs, but managing windows and frames is not the one.
I think your perspective is perfectly valid, and I'd never advocate for dumbing down display-buffer-alist, but I do think some sort of package which makes common buffer configurations easy for novices who haven't put the effort in would make a big difference without getting in the way for those who've already grokked it
1 reply →