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