Newshot
Account

Emacs in the Age of Magic

Original text(via Hacker News)

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

The text above was extracted automatically from the source page and may miss images, tables or code blocks. The original is authoritative.

Published by Hacker News
This site only summarises and aggregates; copyright stays with the original author. Headlines and summaries follow the source — where they differ, the original wins.
Read the original ↗