Comment by iLemming | Hacker News Reader

Comment by iLemming | Hacker News Reader

Parent Full thread

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:

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

It took me a little hunting, so:

https://en.wikipedia.org/wiki/Alternating_caps

Found via:

https://wiki.c2.com/?CapitalizationRules

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.

> I wouldn't put too much stock in the agent-shell business. It's got junior dev written all over it

This is absolutely uncalled for. Álvaro is a long-time Emacs advocate and maker of packages, long before LLMs. I guess that's why some Emacs adepts, despite their long-time commitment and contributions, refuse to be called "programmers", notably Prot (Denote), Karthik (Gptel) and Jonas (Magit). They all keep saying they are not, maybe just to avoid this kind of ungracious stigma from random people.

Some FOSS developers are one of the rarest kind of people we need to cherish and respect. They who sustain unpaid, often thankless maintenance work on important infrastructure for years, sometimes it becomes their life purpose, with zero direct financial reward, while fielding entitled bug reports. They don't anticipate any recognition, but at least let's not call their work substandard, it's not like you're getting taxed for using it.

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

(completing-read "How should I take this?" '("ouch" "lol" " ̄\\_(ツ)_/ ̄"))

⬑ Xenodium created agent-shell, in case anyone missed the joke.

> Will probably die

Did anyone ever tell you how badly you suck at prophecies? This unfalsifiable prediction has enormously bad track record: people have called Emacs dead since the 90s, through XEmacs, through every IDE wave since, through Atom, Sublime, nvim, VSCode, Zed, etc.

I'm sure "Anti-AI core community" drinking themselves to oblivion and chugging anti-depressants seeing how many packages for AI integration people keep building¹ and they just can't do anything about it. Bruh, there's literally ongoing threads about built-in LLM support in emacs.devel, the latest one is not even a week old.

Magit being slow is almost entirely git subprocess spawn and output-parsing overhead, which exists in any git porcelain, not something specific to Emacs or elisp². Blaming Emacs for that is blaming the UI for the engine. I use Magit on Mac and it is not slow. It is slower than on Linux, but it ain't unusably slow.

Define "decent harness". First of all you're conflating the layers - ACP is a wire protocol; asking a protocol to be extensible is illiteracy - protocols are meant to be minimal and stable, that's literally their job. eca and agent-shell are ordinary elisp, with hooks, advising, keymaps, same mechanisms every other package uses. If that layer is hookable and advisable, it's extensible in every effing sense; extensibility was never supposed to live in the protocol underneath. Darn, I'm extending eca from inside fucking eca buffer, da fuk you even blabbering about? Whatever, skill issue. Next.

¹ https://www.reddit.com/r/emacs/comments/1uwm3c0/the_state_of...

² https://news.ycombinator.com/item?id=49634649

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.

Don't tell anyone: https://github.com/agzam/.emacs.d/blob/main/modules/ai/gptel... There's a fear among third-party Claude tool-builders that Ant will close the shop very soon, making it hard for them to use it. Like they did with OpenClaw. I'm sure some inventive hackers still doing it anyway.

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 wonder what you'll think of Paneditor.

It's like "what if the web browser became emacs".

I want to build it because it would put an experience with the level of power described so thoroughly here onto every device simultaneously. I think it would be an incredible boon for programming literacy.

At the same time we could make programming feel natural to do on touchscreen devices, and in languages other than English. Combined with just having a place to play and learn (a reason to write little programs) my hope is that such a tool could inspire a new generation of programmers who previously were locked out

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.

The ONE thing that has me (so far!) using Obsidian instead of Emacs with my agent has been that org mode on mobile is such a clunky experience. Admittedly Orgzly exists for Android, but at the end of the day, org-mode's UX is designed around the keyboard and it hasn't been well enough adapted to the mobile experience.

I've been considering trying it out anyway and seeing what I can do to smooth things out though. Still really getting a hang of exactly how to best integrate external memory in the form of notes with my agentic setup. Was looking at some second brain approaches (such as Zettelkasten) but a lot of that just feels like throwing information into a pile that is more likely to chew through tokens and not provide much benefit with the AI, even if it might well be a really neat way to keep more old fashioned notes.

If you use Hermes, one tip: `session_search` allows searching through all past sessions via full text search. So you don't need to load the notes in every turn.

Another hard part is that your vault of notes and the agent's memory are separate. They can drift apart. We, at Substrate, have solved this with our memory architecture. With it, all of your notes are considered as one memory, and we can always attribute a source to each fact.

What notes does your agent use in a given session? https://trysubstrate.co/l/a2hn

https://old.reddit.com/r/emacs/comments/1xityhe/bloom_now_av... people have been making so many android org apps lately

Strangely enough, the lack of Grammarly integration stops me from using Emacs entirely (after being a zealous user for years).

Let me know if this has changed!

https://github.com/emacs-grammarly

Reply on news.ycombinator.com