Emacs in the Age of Magic

Emacs In the Age Of Magic or, Rome Wasn't Built In A Day, More Like 10 Minutes That's the rule. That's the goal now. What are we doing? What's going on?" -- Jeremy Culhane impersonating Tucker Carlson Look, we want you to express yourself, okay? -- Chotchkie's Manager, Office Space (1999) I began using Claude Code about a year ago in September 2025. For a good week, I woke each morning pinching myself to make sure what I'd witnessed the day previous actually happened. Its handling of all aspects of the coding process blew my socks off then, and it's an order of magnitude more capable now. On the time scale of our species, the digital age has barely just begun. When I graduated with a computer science degree, the field was largely at a stage Churchill might call the "end of the beginning." And yet, just a quarter-century later, no matter where you turn online you can't escape the faint but persistent chime of the death knell. It seems a longstanding problem in maths or theoretical computer science falls to a toaster on the daily. In what Scott Aaronson is calling The Mathocalypse, OpenAI's latest model took all of three hours to carpet bomb 8,000 research problems, resulting in 372 likely hits, some of them career-makers had they been solved by a human. When we say "digital age" we mean a state of the art in which sealed up transistors can reproduce the same outputs given the same inputs with unerring precision. The power to unambiguously differentiate an on- versus an off-signal -- the binary "digital" -- might seem trivial, but is 100% the reason why we're so comfortable handing over the reins to computers. And up until the advent of stochastic AI, it's this rigid adherence to instruction that underlies our world view of technology. So when the first AI scientists touted their "expert systems," we scut programmers tittered inwardly. Our sanitized, sequential conception of software could never admit a ruleset so comprehensive as to cover arbitrary, unbounded behaviors in a real-world system, one like human dialogue for instance. RMS appeared in a recent video recounting his CSAIL work on a circuit analyzer in which he, and I'm paraphrasing, "didn't model the circuit as a system of equations to be solved, but rather approached it much as a human would" by applying a series of diagnostics. I know -- he sounds downright foolish, and would have sounded so even fifteen years ago. But at the time, rules-based programming was still novel enough to be considered a viable approach to AI. In particular, the feedback loop and the physical ergonomics of programming were vastly improving over workflows only recently migrated from punch cards. When single computers still occupied entire rooms, running your program often meant walking it a floor down then waiting for a slot in the queue, an act of barbarism akin to dropping off your camera roll at the photomat. When RMS was slumming it at CSAIL, it was considered a major achievement just to have your text editor echo back onto the screen what you just typed! Given how much more pleasant the act of programming was becoming, people thought the rules-based paradigm could, with far fewer man-hours than ENIAC would have required, encode enough of the world to pass itself off as a sentient intelligence. Natural language understanding, for reasons not entirely clear to me, was considered AI-complete and possessed the massive advantage of having a testable eval over say birdsong, which the early CMU folks initially investigated. The right programming language for AI surely would have to parallel the inherent recursion of human grammars. And so for most of the Chomsky era of language research, LISP/Scheme was the instruction set of choice (and to a lesser extent, the equally recursive Prolog). Richard Gabriel has written some interesting stuff about the philosophical divide between the two bastions of East Coast computing, Cambridge and Murray Hill. One catered to the fuzzy "just do what i mean" semantics of academia, while the other hewed to the buttoned-up strictures of industry. Unsurprisingly, LISP was a lot slower than C, but what it lost in economy of execution, it made up for in economy of expression. LISP was clearly cobbled together without manager supervision, and chose symbols that seemed "good for now." While C contains oddities like "creat" and "strpbrk", at least they're based on actual words. LISP's enigmatic "car" and "cdr" defy any lay attempt at comprehension. Which brings us, after a thousand words of prolix setup, to the subject of emacs. Whither now, we ask -- now that we have, even to my jaded eye, a god machine that makes short work of all the stuff we emacsers believed we were faster at than people using lesser tools. Editing speed, customization, the expressiveness of LISP: every advantage we claimed vanished the moment we stopped typing and started telling the AI what we wanted. We may have felt safe bringing a gun to a knife fight, but now everyone's just sending a drone. Take git commit via magit for instance. We thought ourselves so slick with our C-x g (magit screen), S (stage all changes), c c (commit), rattling off a meaningless commit message in ungrammatical English, then a final C-c C-c for the win. Now Claude Code knows to prompt a grayed out "commit" after making a discrete chunk of changes, so all that's required is a quick tab-return. You win, Claude wins, and Anthropic gets a co-author credit in your git history. The only question is whether you should get a co-author credit. While we figure it out, we can find amusement in the following two case studies in which a noob took a feasible, if not sound, conclusion to its absurd limit. Case Study 1, excali-mode.el ---------------------------- You: I put a picture hook up on the wall. Gaude: Nice, I know exactly what to hang there. [Leaves and comes back ten minutes later with a painting.] You: Is that the Mona Lisa? Gaude: I'm Gaude. I do what I can. I can easily imagine the thinking behind excali-mode. The emacs people announce a new API for a canvas widget, and a high schooler muses, "Hmm, what's a popular drawing app?" The Qwen dialogue might have proceeded as: Student: There's a new canvas widget in emacs. Make excalidraw use it. Qwen: I'm afraid Excalidraw is implemented as a React component. It is currently integrated in Electron apps which feature a React-aware browser under the hood. You may want to consider xwidget-webkit but that won't leverage the new canvas API. Student: I want to use the new canvas API. Qwen: You got it. Qwen then proceeded to *reimplement* Excalidraw's entire stack following a one-for-one substitution of the relevant layers. +-------------------------------------+--------------------------------+ | Excalidraw (web) | excali-mode | +-------------------------------------+--------------------------------+ | browser | Emacs | +-------------------------------------+--------------------------------+ | JavaScript (compiled from | Elisp | | TypeScript) | | +-------------------------------------+--------------------------------+ | rough.js and Excalidraw's render | the C module (excali-rough.c, | | code (JS) | excali-render.c, ... | +-------------------------------------+--------------------------------+ | Canvas 2D API (ctx.stroke(), | Cairo, with Pango for text | | ctx.fillText()), backed by Skia in | | | Chrome | | +-------------------------------------+--------------------------------+ | the page's element | Emacs 32's canvas image | +-------------------------------------+--------------------------------+ No pre-AI developer would ever attempt such insanity, even under the penalty of discharge. He'd 100% quit before subjecting himself to porting an entire application stack for what is clearly a toy purpose. That, for better or worse, is no longer the case. Such quixotic forays now cost nothing but tokens. Case Study 2, cooked.el ----------------------- You: Can you attend my wedding in Mexico? Gaude: Sure can. You: Awesome, which airlines are you taking? Gaude: [Pauses] There, I built my own Boeing. Want to come with? You: Come again? Gaude: I'm Gaude. I do what I can. About a month ago, r/emacs discussed building a terminal emulation mode that preserved all of comint's quality-of-life advantages. This means nothing to the casual reader, but the gist is a terminal emulation mode that presents most straightforwardly as a plain text buffer. One respondent, whose reddit badge purported emacs mastery, described such buffer output as being "cooked." A high schooler reading this must have said to himself, "This master of emacs can't implement this. I myself am not a master, but this man needs my help!" A couple days later, the high schooler posted his solution cooked.el which right off the rip apologized for AI use yet sought credit for being "very strongly and directly designed by me." And by Jove, the design does appear clean and rational, at least how Claude described it to me. Then again, Claude also wrote the code. But there's one glaring headscratcher, and that's its full-blown, self-contained implementation of a terminal emulator, in Rust no less. In the before times, a developer would undoubtedly seek such a heavy lift from off-the-shelf kit, but the holmes replicated over a coffee break what a billionaire with infinite resources had been toiling over the last five years. It probably never occurred to the high schooler that a custom built Boeing materialized in the backyard when all he intended was a new flight stick design. Then there are the projects for which a top-to-bottom reimplementation is warranted. These would include emacs's longstanding grand challenges like replacing Elisp with Guile Scheme, or preemptive LISP threads. I believe a sufficiently interested emacs developer with a $100 plan and a long weekend could hammer out a pretty good first cut. That no one's yet done it is clear evidence that no one really wanted these things so much as they wanted to talk about it. Several years ago, there was a guy whose grandiose plan for rejuvenating emacs made the rounds on YouTube before falling back into obscurity. Dude never wrote a single line of code to realize his vision, but his talk became a rallying point for new users appalled by emacs's lack of Electron-like web interop. Loud bellyaching, or massaging a nice-to-have into a should-have-had, is a potent social hack. It's how politicians win elections. It's why complaining is so fun. You get all the attention and none of the work. Alas, among users whose self-worth isn't tied to code quality, which is most of the population, the proliferation of custom one-offs will continue apace. A recent Hacker News thread featured an article titled "The Emacsification of Software" in which the author describes having AI write a markdown viewer according to his exact preferences. He predicts all applications will get similarly personalized, even ones of disassemblable closed source. He nails the ethos of r/emacs perfectly as "0% Product Hunt and 100% Show and Tell." No longer would software makers try to enforce uniformity across a release. Everyone would have their own private idaho of throwaway hacks, something we finicky emacs users have long been used to. As excali-mode.el and cooked.el illustrate, traditional notions of wastefulness lose meaning when building up and tearing down are as easy as flipping a switch. If AI models do prove to become Dario's "machines of loving grace," then it's just a matter of time before we entrust them with writing directly to the hardware. And how God-like would that be? It's one thing to map behaviors to a high-level language. Mapping them to machine code would require the same higher-dimensional translation that produced life from a gobbledygook of ACGT base pairs. The irony is rich that AI has turned Stallman's goal of software freedom on its head. Having your computer do whatever your imagination can think up -- that's real freedom. The only catch is you'll have no idea how it works. No one does.