Hacker News (curated)new | past | comments | ask | show | jobs| show hidden

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.



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.


According to `git blame` the oldest surviving code in GNU emacs is:

    lisp/play/studly.el
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.)


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.


The biggest value of gptel is its API. I can send a request anytime, anywhere, from pretty much any buffer. I sometimes ask things in the middle of typing a message, or I can ask a model to reword the prompt I'm about to send to another model.

Doesn't work with my github enterprise with entra sso integration. I left a question on github gptel but no progress as of yet. That drove me to agent-shell which requires a cli but works.

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.

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

> some sort of package which makes common buffer configurations easy for novices

Experts often do forget their own "beginner's journey", but I honestly never remember struggling with where windows do appear in Emacs. Either because I never had any eccentric expectations of how this should work, or maybe because I had far bigger issues back in my beginnings. Maybe I didn't notice anything until I found Spacemacs, which had just started gaining some traction back then. I don't remember if they've done anything to improve beginner experience, but then, moving off Spacemacs I might have gotten annoyed, which iirc forced me to understand display-buffer-alist. And then trying Doom, I believe I had to explicitly disable all their novice-aimed improvements and rely on display-buffer-alist settings I was already comfortable with. So, I guess it's a difficult balancing game - need to make it intuitive for the beginners, while not screwing it up for the experts. I mean, if Emacs v32-33 ships with "improvements" that somehow mess with my display-buffer-alist, I'd probably get mad for like two minutes. But that's me, if anything like that to happen, I'm sure it will generate some 2000-message-long discussion thread on emacs.devel.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact | github