thoughtbot
Emacs survives because keyboard-driven programmability outperforms graphical IDEs, but Metzger warns the tool faces obsolescence unless developers introduce true concurrency, WebKit buffers, and modernized runtimes without diluting features for casual users.
AI-assisted summary of The Editor of a Lifetime — original source. Check the original for full context.
Source published:
Key ideas
- Emacs and vi survived nearly four decades of computing shifts through natural selection, emerging in 1976 when serial video terminals first enabled full-screen positional cursor control. (9:52)
- Mastering Emacs requires an upfront investment of two to four weeks, but Perry Metzger argues this cost yields an unmatched return by saving minutes to hours of editing effort every day over a multi-decade career. (24:11)
- Emacs's single-threaded architecture remains its primary structural bottleneck, causing buffer-wide UI freezes during long I/O or regex computations and forcing power users to run multiple instances concurrently. (35:29)
- Rather than attempting ground-up rewrites that discard 30 years of packages, Metzger advocates incremental modernization by embedding WebKit, running a modernized Lisp in parallel on the existing C runtime, and adopting LLVM for semantic parsing and JIT compilation. (28:41)
Detailed notes
## Background Published by thoughtbot on YouTube on August 20, 2014, this talk features Perry Metzger reflecting on his nearly 31 years of using Emacs as his primary computing environment. According to the video description, the presentation combines history, philosophy, and future speculation to explain why computer professionals still dedicate themselves to a terminal-era editor requiring dozens of keystroke sequences in an age of modern GUIs and smartphones.
## TL;DR Perry Metzger examines the longevity of Emacs, arguing that its survival since 1976 is the result of natural selection favoring keyboard-driven editing speed, radical extensibility, and an open architecture that functions like a personalized operating system. He contends that software professionals spend their careers manipulating text, making the steep initial investment in an adaptable, lifetime tool extraordinarily economical compared to transient commercial IDEs. To prevent the editor from stagnating, however, Metzger outlines necessary evolutions, including overcoming its single-threaded runtime, integrating compiler-aware tooling like LLVM, and modernizing web and mail protocols. Throughout the talk and audience exchange, he emphasizes that Emacs remains viable only if the community continues incrementally modernizing its foundation while maintaining backward compatibility.
## Atmosphere & style The presentation carries the warmth and irreverence of a classic hacker gathering, blending veteran systems nostalgia with pragmatic technical critique. Metzger speaks with dry humor and candid conviction, punctuating architectural breakdowns with sharp jabs at modern software bloat, ergonomic missteps like wrist rests, and historical oddities from the DEC and Symbolics eras. The room crackles with insider camaraderie during the extensive Q&A, where knowledgeable audience members eagerly swap war stories about TOPS-20, challenge runtime assumptions, and debate keyboard hardware.
## Bulletin - [09:52](https://www.youtube.com/watch?v=VADudzQGvU8&t=592s) Emacs and vi survived nearly four decades of computing shifts through natural selection, emerging in 1976 when serial video terminals first enabled full-screen positional cursor control. - [24:11](https://www.youtube.com/watch?v=VADudzQGvU8&t=1451s) Mastering Emacs requires an upfront investment of two to four weeks, but Perry Metzger argues this cost yields an unmatched return by saving minutes to hours of editing effort every day over a multi-decade career. - [35:29](https://www.youtube.com/watch?v=VADudzQGvU8&t=2129s) Emacs's single-threaded architecture remains its primary structural bottleneck, causing buffer-wide UI freezes during long I/O or regex computations and forcing power users to run multiple instances concurrently. - [28:41](https://www.youtube.com/watch?v=VADudzQGvU8&t=1721s) Rather than attempting ground-up rewrites that discard 30 years of packages, Metzger advocates incremental modernization by embedding WebKit, running a modernized Lisp in parallel on the existing C runtime, and adopting LLVM for semantic parsing and JIT compilation.
## Key takeaways - [09:52](https://www.youtube.com/watch?v=VADudzQGvU8&t=592s) The emergence of screen editors like Emacs and vi in 1976 was driven by hardware natural selection as full-screen video terminals like the VT52 replaced paper teletypes. - [12:59](https://www.youtube.com/watch?v=VADudzQGvU8&t=779s) Anchoring hands to the home row without relying on mouse input allows developers to manipulate text at the speed of thought, making keyboard-driven editing vastly more efficient than modern GUIs. - [15:48](https://www.youtube.com/watch?v=VADudzQGvU8&t=948s) Having any viable extension language was historically more important than having an elegant one; extensibility transformed Emacs from a text editor into a programmable application platform. - [17:05](https://www.youtube.com/watch?v=VADudzQGvU8&t=1025s) Emacs functions effectively as a specialized operating system for text, and its open-source portability across C and Unix environments guarantees long-term survival independent of corporate vendors. - [19:34](https://www.youtube.com/watch?v=VADudzQGvU8&t=1174s) Like master machinists who construct their own jigs and cutting tools, professional software engineers must be toolsmiths who prioritize workflow efficiency over superficial visual polish. - [24:11](https://www.youtube.com/watch?v=VADudzQGvU8&t=1451s) Because computer professionals spend their entire careers reading and editing text, an editor's endurance and customization capabilities provide compounding returns on investment over decades. - [28:41](https://www.youtube.com/watch?v=VADudzQGvU8&t=1721s) To escape the architectural baggage of Emacs Lisp without breaking legacy code, developers could introduce a modern Lisp dialect running in parallel atop the existing Emacs runtime and buffer primitives. - [33:18](https://www.youtube.com/watch?v=VADudzQGvU8&t=1998s) Emacs should query external compiler infrastructures like LLVM and Clang for semantic code analysis and refactoring rather than attempting to maintain fragile internal parsers. - [35:29](https://www.youtube.com/watch?v=VADudzQGvU8&t=2129s) A lack of concurrency locks up the entire Emacs interface during heavy computation or I/O, driving users to run multiple isolated editor processes as an awkward workaround. - [37:45](https://www.youtube.com/watch?v=VADudzQGvU8&t=2265s) Embedding WebKit directly into Emacs as a first-class buffer would allow users to browse web pages and read modern HTML email without losing native keyboard navigation and search. - [42:28](https://www.youtube.com/watch?v=VADudzQGvU8&t=2548s) Modern consumer and laptop keyboard layouts neglect touch-typing ergonomics by stripping away symmetric modifier keys, unlike historical Lisp machine keyboards designed specifically for programming. - [01:01:55](https://www.youtube.com/watch?v=VADudzQGvU8&t=3715s) Dumbing down Emacs to cater to casual users risks repeating the missteps of desktop environments like GNOME, alienating power users without genuinely serving novices. - [01:05:43](https://www.youtube.com/watch?v=VADudzQGvU8&t=3943s) The only viable future for Emacs relies on pragmatic, incremental modernization—such as adopting off-the-shelf thread-aware garbage collectors and LLVM-backed JIT compilation—to preserve its vast package ecosystem.
## Detailed walkthrough ### [00:14](https://www.youtube.com/watch?v=VADudzQGvU8&t=14s) Thirty-One Years of Emacs
Perry Metzger introduces his talk by reflecting on a milestone: he has now been using the Emacs text editor for 31 years (minus about four weeks), having first learned it as a college freshman in September 1983. He notes that the state of the art in computing has shifted dramatically since those early days. In 1983, the premier user interface at Columbia University was the DEC VT100 terminal. Students would camp out and fight for time on a VT100; if you were relegated to one of the older Lear Siegler terminals, you were deeply unhappy.
Metzger recalls that his primary operating system at the time was TOPS-20 running on a DEC-20 mainframe. He jokes that the massive machine was "somewhat larger" than his current computer, lacked USB ports, and is not something he actively misses using for daily work. While retro-computing holds some nostalgic value, he points out that "no one wants to use museum hardware," especially considering that many people in his audience were not even born yet in 1983. This raises a fundamental question about software longevity.
“Why would anyone use a program that long? I won't say why would anyone in their right mind use a program that long because there might be some debate on that question, but why would anyone use a program for that long?”
[03:37](https://www.youtube.com/watch?v=VADudzQGvU8&t=217s) The "Bootloader for Emacs"
For Metzger, Emacs is not just a text editor; it is the central hub of his entire computing environment. He uses it for software development, writing presentations in LaTeX, chatting, and managing his calendar and phone book. Although he recently stopped using it to read email because IMAP and HTML support in the built-in mail readers had grown too outdated, he fully intends to return to it once those features are improved.
He is far from alone in this level of devotion. Metzger shares an anecdote about a PhD student at the University of Pennsylvania who, when asked why he tolerated a particularly frustrating operating system on his laptop, replied that he did not care because the OS was "just a bootloader for Emacs." Similarly, Penn professor Benjamin Pierce conducts his CIS 500 lectures by running Proof General inside Emacs to demonstrate proofs in the Coq proof assistant. Metzger even has a completely non-technical friend who uses Emacs for his daily calendar, to-do lists, and text editing. This deep-seated enthusiasm explains why communities organize dedicated Emacs meetups and clubs.
“I don't care, it's just a bootloader for Emacs.”
[07:23](https://www.youtube.com/watch?v=VADudzQGvU8&t=443s) Skeptics, Competitors, and Marketing Failures
Metzger addresses whether Emacs's multi-decade survival is due to ease of use, aesthetics, or clever marketing. He quickly dismisses these ideas. Emacs is notoriously difficult to learn, it is certainly not the prettiest editor, and historical commercial marketing efforts—such as those by Unipress Software—were such massive failures that it is difficult to find any mention of them online today.
Outside the Emacs community, many developers look at the tool with utter bewilderment. Metzger's own brother, a doctor, uses a modern IDE and has likely never tried Emacs, probably assuming its advocates are crazy. During his time teaching, Metzger has had students show up to office hours using basic tools like Notepad++ or the built-in Microsoft text editor. While he respects the vi users in his lab, he acknowledges that to the uninitiated, the devotion of Emacs users looks less like a rational choice and more like a shared eccentricity.
“Is it because Emacs is so well marketed? And everyone remembers that in fact Unipress tried to market Emacs, and everyone knows what a great commercial success Unipress is to this day, right?”
[09:52](https://www.youtube.com/watch?v=VADudzQGvU8&t=592s) Natural Selection and the Rise of Screen Editors
To explain why Emacs has survived so long, Metzger points to a process of "natural selection" in software history. Up until the mid-1970s, the primary interface to a computer was a paper-based teletype. Working on highly constrained systems—such as a PDP-8 running OS/8, or a PDP-11 running RSTS/E—forced programmers to use line editors because there was no alternative.
The introduction of "glass TTYs" saved paper but did not change the underlying editing paradigm. However, by the mid-1970s, commercial serial terminals with full-screen positional cursor control, like the DEC VT52, finally hit the market. This technological shift made screen-based editing possible. It is no coincidence that both Emacs and vi were born in the exact same year: 1976. While hundreds of screen and structure editors were created during this era, only vi and Emacs survived because users fell in love with them so deeply that they insisted on keeping them alive. Metzger argues that the creators of Emacs were not just lucky; they were incredibly smart designers who built a highly adaptable system.
“1976 is the year Emacs shows up, 1976 is the year VI shows up. I do not see this as a coincidence at all; it was a response to the fact that the technology finally became possible.”
```mermaid flowchart TD accTitle: Evolution of Text Editors and Terminals accDescr: A flowchart showing the transition from paper-based teletypes to full-screen serial terminals, leading to the creation of Emacs and vi in 1976.
A["Teletypes (Pre-1970s)"] -->|"Paper-based output"| B["Line Editors"] C["Glass TTYs (Late 1960s)"] -->|"Saved paper, no scrollback"| B D["Serial Terminals (Mid-1970s)<br>e.g., VT52, VT100"] -->|"Positional cursor control"| E["Screen Editors"]
B --> E E -->|"Natural Selection (1976)"| F["Emacs"] E -->|"Natural Selection (1976)"| G["vi"] ```
[12:59](https://www.youtube.com/watch?v=VADudzQGvU8&t=779s) The Genesis of TECO Macros and Keyboard-Driven Speed
Tracing the history of Emacs back to its origins, Perry Metzger recounts how Richard Stallman, Guy Steele, and their peers began improving TECO’s Control-R mode—a real-time editing feature Metzger quips is “best forgotten”—by writing macro packages on top of it. Because the source code was freely shared among exceptionally talented hackers, the system evolved rapidly. Whether the resulting architecture was pure brilliance or a lucky accident, Metzger insists it hit upon the right design. Editing with menus and mice is fundamentally too slow for people who write for a living, whereas Emacs allows a programmer to modify text at the speed of thought. By keeping both hands anchored to the home row, actions like opening files, switching buffers, running builds, indenting, and invoking debuggers occur seamlessly without reaching for a pointing device.
Metzger illustrates this difference with the simple mistake of transposing two letters. In a modern graphical editor, a developer who notices the typo halfway across the line must stop typing, reach for a mouse or arrow keys, click between the letters, hit backspace or delete, and retype the character. In Emacs, the user simply executes `C-t` to transpose them instantly and continues typing without breaking cadence. Metzger jokes to the nodding audience members that GUI-based editing drags by comparison, noting that those who have not used Emacs long enough often fail to realize how deeply transformative such immediate keyboard control becomes.
```mermaid flowchart LR accTitle: Editing Speed Comparison accDescr: Contrasts modern GUI text editing friction against the Emacs keyboard-driven workflow. subgraph GUI["Standard GUI Workflow"] A["Notice transposed letters"] --> B["Reach for mouse"] B --> C["Click, delete, & retype"] C --> D["Return hands to home row"] end subgraph Emacs["Emacs Workflow"] E["Notice transposed letters"] --> F["Strike Control-T"] F --> G["Continue typing immediately"] end ```
- Stallman, Steele, and others initially built macro packages directly inside TECO. - The open availability of source code within the MIT AI Lab hacking community drove rapid experimental iterations. - Metzger emphasizes that “in Emacs you can change text as fast as you think.” - Keystroke-driven macros allow users to execute sweeping, repetitive mass edits across codebases without having to write dedicated scripts.
---
[15:48](https://www.youtube.com/watch?v=VADudzQGvU8&t=948s) Extensibility: From TECO to Elisp and the Editor as an Application Platform
Extensibility proved to be the pivotal breakthrough that secured the editor’s longevity. TECO itself was a notoriously arcane and cryptic language, but Metzger emphasizes that having any viable extension language was vastly more critical than having an elegant one. He sees an exact parallel in modern GNU Emacs: Emacs Lisp (Elisp) may be considered a mediocre programming language by contemporary standards, but its sheer existence and ubiquity make it effective. Because Emacs was built to be programmable, developers transformed it from a plain text manipulation tool into an integrated platform hosting mail clients, interactive debuggers, full IDE environments, and refactoring utilities.
Metzger contrasts this open flexibility with modern proprietary environments like Xcode. If a developer using Xcode encounters a missing feature or an editor behavior that the original engineering team never anticipated, there is virtually nothing they can do to fix it. With Emacs, if a simple macro proves insufficient, the user writes a few lines of Lisp code, drops it into their initialization file (`~/.emacs`), and instantly redefines the environment. Emacs ceases to be merely an editor; it operates as a flexible user interface designed for building and running applications where text manipulation happens to be a primary requirement.
- Metzger argues that “TECO was a terrible extension language, but the fact that it existed was more important than that it was good, and in fact I would argue that in some sense that's the situation with Elisp today.” - When TECO was abandoned, Lisp became the universal extension language across Emacs implementations, culminating in GNU Emacs. - Extensions in Emacs function as complete applications embedded directly into the text workflow. - In contrast to rigid integrated development environments, user-level extensibility empowers programmers to resolve workflow bottlenecks on the fly without waiting for upstream vendor updates.
---
[17:05](https://www.youtube.com/watch?v=VADudzQGvU8&t=1025s) Email in an Editor and the "Operating System" Critique
To non-Emacs users, running applications like email clients inside a text editor sounds bizarre. Metzger counters that the arrangement is entirely natural: drafting an email is primarily an act of text editing. He laments the modern state of email correspondence, pointing out that colleagues using Microsoft Outlook or mobile apps on iPhones struggle to manipulate text effectively. Rather than employing traditional point-by-point inline quotes to address multiple discussion items thoroughly, modern email users are hamstrung by their interfaces, leaving them capable of sending only brief, poorly composed two-line replies. Composing inside Emacs allows writers to leverage full editing ergonomics—cutting, pasting, reformatting, and quoting text effortlessly to create high-quality communication.
Addressing the long-standing community critique that Emacs is a bloated, sprawling pseudo-operating system, Metzger completely rejects the premise that this is a flaw. Drawing laughs from the audience, he recalls his time maintaining the NetBSD operating system, where he actually coded a tongue-in-cheek easter egg into the NetBSD bootloader, only to have someone without a sense of humor scrub it out years later. Rather than denying that Emacs mimics an OS, Metzger embraces the label and argues that current Emacs implementations actually fall short of what a full operational environment should provide.
- Metzger directly refutes the operating system insult: “You say that it's an operating system like that's a bad thing; it's not a bad thing, it's a good thing.” - Traditional point-by-point email quotation has deteriorated because GUI mail clients fail to provide expressive, keyboard-driven text manipulation tools. - Metzger maintains that Emacs is currently more of a specialized UI framework than a true operating system, though he advocates pushing it further in the OS direction. - As a longtime NetBSD core developer, Metzger once introduced an Emacs-related easter egg directly into the NetBSD system bootloader before it was eventually removed.
---
[19:34](https://www.youtube.com/watch?v=VADudzQGvU8&t=1174s) Toolsmithing and the Professional Ethos
Metzger highlights how mainstream commercial development tools eventually validated Emacs’s integrated vision. Products across the IDE landscape—ranging from Apple’s Xcode to what Metzger jokingly dubs the “Microsoft Visual Blight” suite—eventually adopted the Emacs model of combining source editing, compilation, and interactive debugging within a single interface. However, commercial IDEs missed the fundamental advantage: their interfaces remain closed, denying developers the power to reprogram and customize the tool itself. Metzger insists that crafting and reshaping software tools is central to computer science, drawing a direct parallel to master machinists, who spend a significant portion of their workday fabricating custom jigs, cutting tools, and fixtures to produce intricate parts efficiently.
Metzger notes that software professionals likewise write programs to streamline their daily labor, with entire corporate roles dedicated purely to developer environment maintenance and toolsmithing. Because Emacs was ported to C and Unix under an open source license, it achieved operational permanence. Unlike proprietary editors that inevitably vanish when parent companies collapse, merge, or discontinue product lines, Emacs survives independent of any single platform or corporate entity. Metzger concludes with an analogy to commercial restaurant kitchens: just as professional chefs eschew decorative granite countertops, handcrafted oak cabinetry, and red-enameled Viking stoves in favor of raw, durable stainless steel to churn out hundreds of dinners a night, software professionals must value efficiency above superficial visual polish.
- Machinists provide an engineering precedent for programmers, spending substantial working hours building and adapting custom tooling to handle challenging fabrication jobs. - Metzger points out that proprietary programs die alongside the platforms they were written for or the corporations that sold them. - Emacs’s portability across Unix and the C language ensures that once a developer masters it, that operational knowledge remains valuable across multiple decades. - Metzger delivers a sharp assessment of professional tools: “Computer scientists also need their tools to be efficient; pretty is not a concern, getting your work done quickly is a concern.” - At their core, computer professionals spend their careers executing only two fundamental tasks: reading text and writing text.
[24:11](https://www.youtube.com/watch?v=VADudzQGvU8&t=1451s) The Economics of Text Editing and Editor Longevity
Perry Metzger explains that programmers and systems administrators spend their entire working lives editing text—whether documentation, web pages, software source code, or administrative utilities. Because professional productivity directly hinges on how efficiently one edits, the efficiency of the editing tool matters far more than superficial graphical flourishes like vector icons with blended shading or interface animations. Metzger emphasizes that endurance is an essential feature of software: mastering an editor requires significant effort, and that investment is only rational if the tool outlasts transient computing trends.
Metzger notes that it took him a couple of weeks to become proficient with Emacs, and roughly a month before he was working without conscious effort. Over the subsequent three decades, that upfront cost has saved him anywhere from a few minutes to several hours every single day, yielding an extraordinary return on investment. Emacs has survived for almost forty years because it serves as an open-source, fully customizable computing environment that users can practically inhabit. However, Metzger warns that failing to adapt could still cause Emacs to die, arguing that despite substantial past updates—such as window system integration and networking capabilities—it must evolve further to stay relevant.
> “This is an amazing return on investment you know this is this is you know this is a fine fine thing so why has Emacs survived it's because it's a great editor that you can practically live in you can do everything inside it uh you can extend it you can customize it so if it doesn't do something you want you can make it do it uh you will never have to stop using it because it's open source and and can be ported to almost anything and if you're a computer professional that's irresistible and that's why there are Fanatics in this world and that's why we find ourselves at an Emacs Meetup” — Perry Metzger
- Writing large-scale software requires a specialized tool; basic editors like Notepad are fundamentally inadequate. - Emacs users no longer rely on physical VT100 terminals; they run Emacs directly in modern graphical user environments or via terminal emulators over SSH. - Key areas Metzger identifies where Emacs must adapt include modernization of its extension language, deep refactoring capabilities, true concurrency, and better personal information manager (PIM) protocol integration.
---
[28:41](https://www.youtube.com/watch?v=VADudzQGvU8&t=1721s) The Limitations of TECO, Elisp, and the Parallel Lisp Solution
Metzger reflects on the history of Emacs extension languages by presenting an unreadable snippet of TECO code. He quizzes the audience on its function, joking that while one might guess it fixes the Y2K bug, the code actually calculates the digits of $\pi$. He recalls an old hacker pastime of typing people's names into TECO to see what unintended program would execute. While moving from TECO to Emacs Lisp (Elisp) was a massive leap forward, Metzger contends that Elisp remains profoundly inadequate for building large modern applications. Elisp only recently added lexical scoping (and only if explicitly requested), lacks namespaces and modularity, and is saddled with decades of poorly designed legacy APIs that accreted without a coherent architectural plan.
```mermaid flowchart TD accTitle: Parallel Lisp Runtime Architecture accDescr: Architecture showing legacy Elisp and a modernized Lisp coexisting over the shared Emacs runtime engine.
subgraph UserLand["Extension Layer"] OldElisp["Legacy Elisp Code<br/>(Existing packages & modes)"] NewLisp["Modernized Lisp<br/>(Modules, namespaces, lexical scope)"] end
subgraph EmacsCore["Emacs Engine & Runtime"] SharedRuntime["Shared Runtime & Memory Space"] BufferEngine["Buffer & Text Manipulation Primitives"] LegacyAPIs["Legacy Accreted APIs"] CleanAPIs["Modernized Clean APIs"] end
OldElisp --> LegacyAPIs LegacyAPIs --> SharedRuntime NewLisp --> CleanAPIs CleanAPIs --> SharedRuntime NewLisp -.->|"Cross-calls & interoperates"| OldElisp SharedRuntime --> BufferEngine ```
When an audience member asks about using Common Lisp instead of inventing new dialects that fragment the community, Metzger clarifies that he is somewhat agnostic on the specific dialect, but proposes running a second, modernized Lisp in parallel on the existing Emacs C runtime. Drawing an analogy to how non-Java languages leverage the JVM, Metzger argues that Emacs already provides a working runtime with essential text-editing primitives like buffers. Developers could build a clean, modern Lisp engine directly atop that runtime without throwing away existing packages, gradually introducing clean, non-revolting APIs that cross-call into the legacy namespace.
> “I would argue that we have a perfectly good language runtime inside the Emacs interpreter it's true to a first approximation I would not call it the best language runtime but it's it's it's good enough okay there's all of this code that runs in this runtime already uh the runtime provides lots and lots of data structures uh like buffers that one wants in one's editor one could build a second Lisp in parallel that use the same runtime and unlike the JVM situation one is allowed to improve the runtime or add extra features to it while one is so long as it doesn't break the old code while one is improving the system” — Perry Metzger
- TECO code is notoriously cryptic; a popular historical game was seeing what behavior resulted from feeding arbitrary human names into the TECO interpreter. - Elisp historical baggage includes dynamic scope by default, the absence of namespaces, and a lack of true module systems. - Metzger's JVM comparison highlights that alternative languages can thrive on top of an established platform while retaining full interoperability with legacy libraries.
---
[33:18](https://www.youtube.com/watch?v=VADudzQGvU8&t=1998s) Compiler-Aware Tooling and the Concurrency Problem
Turning to programmer tooling, Metzger contrasts Emacs with modern IDEs like Eclipse and Xcode. While Emacs has internal facilities like CEDET, they are largely ad hoc and struggle with complex semantics. Modern development environments bypass internal parsers by querying external compiler infrastructures—specifically LLVM and Clang—for syntax parsing, symbol table generation, code walking, and code completion. Metzger insists Emacs should do the same rather than trying to “reinvent the square wheel,” which would unlock reliable semantic refactoring and auto-completion for complex languages like C++.
Metzger then highlights Emacs's single-threaded architecture as an enduring flaw. Because long-running computations block the entire process, any intense task locks up every window and buffer. To cope with this, Metzger regularly runs three or more separate instances of Emacs simultaneously on his desktop—one for email, others for active programming—so that operations like fetching mail in Gnus do not freeze his ability to edit code. When an audience member asks why he does not simply utilize named compile-mode buffers, Metzger replies that background processes do not resolve the blocking that occurs when an Elisp package enters an internal computation loop.
> “Threading yeah this has been an irritant for me for years Emacs blocks all windows when you are doing computation in any window it it's an operating system but it's not enough of an operating system I myself find you know will run three or more instances of Emacs on my desktop to get around this I'm you know I'm slurping in my email and I can't do something else at the same time because it's often space slurping in my email it's it's going through and it's doing some you know it wants to do some sort of extended computation I can't go into another window and do anything else at the same time this is irritating” — Perry Metzger
- Modern IDEs leverage LLVM/Clang to parse source code directly, giving them access to exact ASTs and symbol tables for refactoring. - Implementing robust AST-level tooling purely within Elisp remains extremely difficult and slow. - Emacs's global interpreter lock and lack of threading prevent users from interacting with one buffer while another buffer executes Elisp tasks.
[35:29](https://www.youtube.com/watch?v=VADudzQGvU8&t=2129s) Threading, Blocking Operations, and the ELisp Process Dilemma
Perry Metzger turns to one of Emacs's longest-standing structural pain points: the single-threaded architecture that causes the entire editor interface to freeze when executing long computations. Metzger explains that when Emacs executes a heavy task—such as prolonged disk I/O, network communication, or evaluating regular expressions over massive buffers—it locks the user out completely. An audience member interjects with a relatable frustration: “We're executing a regular expression over a large buffer over and over again, I just want to go to another buffer!” Metzger agrees, pointing out that because of this lack of concurrency, “some of us end up running multiple Emacs instances in spite of the fact that really for maximum fun you only want to run one Emacs instance.”
Addressing how to solve the problem, Metzger proposes binding threads to individual buffers with buffer-local and thread-local data, which would minimize overhead since global data accesses requiring locks are relatively rare. When an audience member warns that threads would require restricted stack sizes because Lisp burns through stack space, Metzger counters that statically allocated stacks are unnecessary when implementations can use spaghetti stacks or heap-allocated stacks. Another audience member notes that inferior Common Lisp processes run intense computations for hours without blocking Emacs, asking why one can't simply build a proper conduit to an inferior ELisp interpreter. Metzger explains that the fundamental hurdle with separate processes is sharing rich, in-memory data efficiently:
```mermaid flowchart TD accTitle: Proposed Emacs Threading Architecture accDescr: Diagram contrasting buffer-local thread isolation with shared global data requiring locks.
subgraph Buffers ["Thread Isolation per Buffer"] T1["Thread 1 (Buffer A)<br>Local Data / Spaghetti Stack"] T2["Thread 2 (Buffer B)<br>Local Data / Spaghetti Stack"] end
subgraph GlobalState ["Shared State"] G["Global Data Structures"] end
T1 -->|"Isolated execution (non-blocking)"| T1 T2 -->|"Isolated execution (non-blocking)"| T2 T1 -.->|"Infrequent lock"| G T2 -.->|"Infrequent lock"| G ```
- Heavy computational loops inside Emacs Lisp block user input across the entire application because execution currently runs in a single main thread. - As a workaround, power users are often forced to run independent Emacs processes side by side. - Metzger clarifies that while external subprocesses do not block Emacs, delegating ELisp evaluation to inferior interpreters breaks shared in-memory data structures.
---
[37:45](https://www.youtube.com/watch?v=VADudzQGvU8&t=2265s) Swallowing WebKit and PDFs: The Drive to Never Leave Emacs
Metzger identifies his primary daily annoyance: the modern compulsion to leave Emacs to read web pages, view rich PDFs, and open HTML-formatted emails. He laments that despite purist objections, HTML email has become an unavoidable reality: “Someday when I am dictator many of you will not may be happy and many of you may be extremely unhappy, but but but we don't really have the ability to do that sort of thing right now.” Rather than attempting to maintain fragile, native HTML parsing engines inside Emacs, Metzger advocates leaning into Emacs's operating-system ambitions by directly embedding WebKit into the core editor:
> “So my solution is again give into the operating system impulse and embed WebKit inside Emacs.”
Metzger insists that running rendering engines inside isolated subwindows defeats the purpose; WebKit buffers must be first-class Emacs buffers. This would allow users to use incremental search (`I-search`), mark regions, and yank text directly into editor buffers. He jokes that embedding WebKit would finally restore Emacs's historical reputation for consuming the vast majority of a machine's hardware resources, contrasting past complaints about an 8-megabyte footprint with modern machines equipped with gigabytes of RAM. In the same vein, he argues for native PDF document inspection with text extraction and regular-expression search, wondering aloud why modern web browsers like Chrome still lack proper regex find capabilities. Beyond rendering engines, Metzger urges deeper integration with modern server protocols, particularly CardDAV for contact management, CalDAV for calendar synchronization, and first-class IMAP support so users can manage emails across phones and desktop machines seamlessly.
- Metzger insists external renderers fail because they isolate UI events; WebKit must share buffer data to support native Emacs navigation and keybindings. - Running large engines inside Emacs playfully revives the era when critics claimed Emacs stood for "Eight Megabytes And Constantly Swapping." - Modern protocol integration (CalDAV, CardDAV, and robust IMAP) is deemed vital to stop users from migrating to dedicated web or desktop clients.
---
[42:28](https://www.youtube.com/watch?v=VADudzQGvU8&t=2548s) The Keyboard Rant: Space Cadet Dreams and Modern Limitations
Metzger shifts into an opinionated critique of contemporary keyboard layouts, displaying an older Apple keyboard to demonstrate the necessity of symmetric modifier keys:
> “I actually like being able to touch type all my control keys and I like having all my shift keys and control keys symmetric on both sides of the keyboard.”
He sharply criticizes modern Mac laptop keyboards for eliminating the right-hand Control key. Moving past standard consumer gear, Metzger displays an image of a Symbolics Lisp machine keyboard—functionally identical in spirit to the legendary Knight-designed Space Cadet keyboard—praising its expansive layout designed specifically for software engineering. He observes how absurd it is that modern programmers remain confined to character repertoires dictated by 7-bit ASCII standards from the mid-1960s, instead of having direct access to mathematical symbols like universal quantifiers ($\forall$), existential quantifiers ($\exists$), arrows, and Greek alphabets via dedicated shift modifiers like Front, Top, and Greek.
Metzger describes the modifier hierarchy he desires: dedicated Hyper, Super, Meta, and Compose keys (the latter allowing sequences like `=` followed by `/` to cleanly produce `≠`). He polls the audience on whether they would fund a Kickstarter project to manufacture a true modern programmer's keyboard. Audience members shout suggestions, asking for embedded ThinkPad-style TrackPoints or buckling spring switches akin to the IBM Model M. Metzger notes that sourcing individual buckling spring switch modules remains nearly impossible because original manufacturing techniques stamped them out as entire unitary assemblies, though he remains open to TrackPoint hardware if suitable motherboard components can be sourced. Metzger then prepares to conclude the presentation by addressing the ultimate existential question: when will Emacs finally die?
- Modern PC and Mac laptop designs increasingly drop right-side modifier keys, frustrating touch-typists who use opposing hands for key combinations. - The Symbolics keyboard featured dedicated modifier layers (Greek, Top, Front) allowing single-chord access to Greek characters, uppercase forms, and mathematical logic symbols. - Metzger highlights the historical curiosity of Roman numeral keys on early Lisp keyboards, explaining they were originally used to select items from pop-up menus before being abandoned in later revisions.
[46:36](https://www.youtube.com/watch?v=VADudzQGvU8&t=2796s) The Longevity of Emacs and the Ergonomics of Keyboards
Wrapping up his prepared remarks, Perry Metzger contemplates what might finally cause Emacs to die. While acknowledging that “nothing lives forever,” he muses that Emacs might persist until keyboards cease to be the fastest way to input text, or until humans develop direct brain-to-machine interfaces. Even in that hypothetical future, however, Metzger notes that users will still demand core capabilities like multiple buffers and deep programmability, making direct neural links merely another input mode. He argues that as long as the community diligently tends Emacs and ensures it remains modern—such as by integrating rendering engines like WebKit—it will continue to attract and retain an active user base into the indefinite future.
Opening the floor to questions, an audience member raises a suggestion about hardware ergonomics, praising the Kinesis Advantage keyboard, which places the `Ctrl` keys directly under the thumbs to eliminate reach and ward off carpal tunnel syndrome. Metzger agrees that proper key placement helps, but shares his own physical experiences: he has managed to avoid major repetitive strain injuries by keeping his typing surface strictly below wrist level. He calls wrist rests “one of the stupidest inventions ever because they don't make your life better, they make your life worse.” The only two times he experienced acute wrist trouble were when experimenting with a wrist rest, and during a grueling three-month trading floor rollout in Midtown Manhattan where he had to type bent-wristed under awful ergonomics, resulting in a brief bout of tendinitis. Beyond having `Ctrl` keys accessible on both sides to minimize awkward reaches, Metzger notes a practical tip: he always removes his wristwatch while typing.
[49:14](https://www.youtube.com/watch?v=VADudzQGvU8&t=2954s) IDEs, Keybindings, and Regular Expressions in Browsers
The discussion turns to integrated development environments versus text editors. An audience member mentions Cedet (CEDET) as an attempt to make Emacs more IDE-like, but Metzger points out that while several IDE layers exist, none can parse complex languages like C++ nearly as accurately as modern compiler infrastructures such as LLVM/Clang—since a compiler inherently must parse the code correctly. Audience member Jay jumps in to emphasize that for long-time Emacs users forced into IDEs like Eclipse or IntelliJ IDEA, the friction is not about the specific binary being executed, but the user interface habits: muscle memory demands `C-s` or `M-s` to launch incremental regular expression searches.
Metzger recounts confronting a lead Google Chrome developer about why web browsers lack built-in regex searching, only to receive the dismissive response that nobody had ever asked for it. Metzger counters that Rob Pike publicly delivered a talk roughly 16 years earlier complaining about the very same omission. An audience member chimes in to defend the browser developers, suggesting that regular expression searching is naturally suited to composition engines where users actively write and manipulate text rather than read-only viewers. Metzger adds that while Emacs is primarily built for generating and editing text, its audience extends beyond programmers to include dedicated prose writers who rely on its fluid text-manipulation power.
[51:05](https://www.youtube.com/watch?v=VADudzQGvU8&t=3065s) JavaScript, Asynchrony, and the TOPS-20 Command JSYS
Jay brings up a recent realization from looking into JavaScript and Node.js via Nadeem Kobeissi's Minilock. He argues that while JavaScript's syntax is ordinary and uninspiring—noting that Brendan Eich originally wished to use a Scheme/Lisp syntax—its operational model is fundamentally different from traditional languages like C, Common Lisp, or BASIC. By default, JavaScript environments operate around listening on arbitrary ports and executing asynchronously via an event loop. Jay connects this directly to Metzger’s critique of the Emacs Lisp runtime:
> “Emacs runtime is a catastrophe, as you devoted... you've got to take asynchronous things seriously.”
```mermaid flowchart TD accTitle: Asynchronous Concurrency Tradeoffs accDescr: Comparison of JavaScript event-driven concurrency versus Emacs multi-threading challenges
subgraph JS["JavaScript / Node.js Runtime"] J1["Event Loop Default"] --> J2["Non-blocking I/O Ports"] J2 --> J3["Async Callbacks & Handlers"] end
subgraph TOPS["DEC TOPS-20 Experience"] T1["Async Command JSYS"] --> T2["Background Command Forks"] T2 --> T3["State Reconciliation Bottleneck"] end
subgraph Emacs["Emacs Lisp Runtime Dilemma"] E1["Single-Threaded Core"] --> E2["Proposed OS Threads"] E2 --> E3["Reconciling Shared Buffer State"] end ```
Another audience member shares a historical parallel from his time in the TOPS-20 development group at Digital Equipment Corporation (DEC). Long before modern windowing or web servers, the team attempted to design an asynchronous command interface inside the DEC command JSYS. Although technically feasible to run commands concurrently in background forks, managing the return values and coordinating completion states back to the user proved so conceptually baffling that technical writers refused to document it, admitting they could neither explain it nor teach customers how to use it. Metzger and the audience reflect that this control-flow reconciliation problem is precisely why shared-memory multithreading is conceptually appealing to programmers, even though handling thread synchronization presents its own steep challenges.
- JavaScript defaults to an asynchronous, event-driven execution model rather than synchronous procedural execution. - Early DEC engineers struggled with user-facing asynchronous flows when attempting to make the TOPS-20 command interface concurrent. - Coordinating what happens when concurrent tasks return remains the hard architectural hurdle in editor runtimes.
[56:22](https://www.youtube.com/watch?v=VADudzQGvU8&t=3382s) Educating Students and the Upcoming DOM Discussion
Metzger reflects on training future software engineers, recalling the mandatory rule he gives to undergraduate students in introductory Unix, Linux, and programming classes:
> “I don't care if you pick Emacs or vi, but you have to pick one of them, and the reason is because you need to have a text editing environment that you will be comfortable in for a very long time to come.”
He shares his sheer exasperation at encountering University of Pennsylvania seniors in an advanced operating systems class who were writing their Unix shell project using Notepad++ on Windows. Despite his best efforts to apply the metaphorical "clue stick" (or LART), some students stubbornly resisted learning an industrial-grade text editor, a habit Metzger believes ultimately prevents them from becoming top-notch professional software engineers. Closing out the segment, Jay pivots back to JavaScript, noting that beyond its asynchronous nature, the language's deepest power and complexity lie in its structural binding to the Document Object Model (DOM), setting up a discussion on structure editors.
[57:59](https://www.youtube.com/watch?v=VADudzQGvU8&t=3479s) UIs Becoming Operating Systems and the Synergy of Code and Editor
Perry Metzger reflects on a broader software pattern: any successful user interface, given enough adoption, inexorably evolves into an operating system. This dynamic played out with modern web browsers and decades earlier with Emacs. When comparing web internals to traditional computing, Metzger questions the fundamental distinction between modern web structures and older abstractions, asking what the real difference is between the DOM and a Unix directory of files. An audience member suggests that the DOM serves as a presentation layer, but Metzger counters that neither system was cleanly designed from first principles: “The whole system accreted from a series of last-minute necessities, right? Even JavaScript itself.”
```mermaid flowchart LR accTitle: The Editor-Language Synergy Loop accDescr: Feedback loop showing how writing code requires an editor and an extensible editor requires code. subgraph Synergy ["Feedback Loop"] direction LR A["Text Editor"] -->|"Provides environment to write"| B["Extension Language"] B -->|"Extends and automates"| A end ```
The discussion shifts to what genuinely makes an editor an "Emacs." An audience member points out that the core power lies in the deep synergy between a text editor designed for writing code and a built-in programming language used to extend that very editor. Whether that extension language is Lisp, JavaScript, or something else is secondary—if an editor integrates tightly with a sufficiently expressive language to manipulate text, it embodies the Emacs philosophy. Metzger agrees, noting historical precedents like Lugaru Software’s Epsilon (an early PC Emacs clone with a C-like extension language called EEL) as well as modern experimental clones built on Haskell. While younger developers might gravitate toward JavaScript, Metzger humorously admits he had to restrain himself from hurling at the idea, though he concedes that JavaScript's Self-style prototype inheritance makes it interesting from a pure computer science perspective.
- Epsilon, produced by Lugaru Software, was an early commercial PC editor modeled on Emacs that used a C-like extension language instead of Lisp. - Haskell-based Emacs variants demonstrate that the architectural philosophy transcends the specific choice of Lisp. - JavaScript's core prototype inheritance model, derived from Self, is acknowledged as conceptually interesting despite Metzger’s visceral distaste for using it as an editor platform.
---
[01:00:50](https://www.youtube.com/watch?v=VADudzQGvU8&t=3650s) Text as Abstract Syntax Trees vs. Plain Characters
An audience member highlights a defining philosophical distinction between Emacs and conventional text editors: editing text in Emacs feels less like manipulating raw characters and more like operating on higher-level abstractions. In Lisp modes, navigation commands operate directly across S-expressions (`C-M-f` to jump forward across an entire balanced expression) or structural units like functions. This ability to construct layers of abstraction over raw text provides immense leverage, echoing the Unix philosophy of chaining small, composable tools together via pipelines to accomplish in seconds what might otherwise take hours of manual effort.
Metzger connects this directly to how he introduces students to the power of programmable editing: > “The first thing to do I found always is to show someone something like vastly refactoring a piece of code with a couple of small macros and then saying to them, ‘Can you do this in Notepad?’ And they inevitably say to themselves, ‘Huh, maybe there is a reason I should care about this.’”
---
[01:01:55](https://www.youtube.com/watch?v=VADudzQGvU8&t=3715s) Accessibility, the Gnome Cautionary Tale, and Modern Tutorials
When asked whether Emacs should be made more accessible to marginal users who might try it and quickly abandon it, Metzger pushes back strongly. He points to the desktop Linux ecosystem as a cautionary tale:
> “I’ve watched, for example, what has happened in the Linux community where the attempt to make GNOME into a more accessible system—also done by people who didn't really understand accessibility very well—has rendered it not useful for the naive user or the sophisticated user.”
Metzger argues that Emacs is fundamentally a tool for sophisticated practitioners who will spend their entire careers editing text, where an upfront investment of two or three weeks yields compounding dividends over decades. Sacrificing features or altering paradigms to appease casual users risks alienating the core community. However, he and the audience agree that pedagogy and documentation need serious attention. When someone mentions complaining about the tutorial years ago to Richard Stallman, Stallman gave the classic hacker response: fix it yourself. Metzger learned from the original tutorial decades ago, and while its core remains solid, it lacks guidance on modern paradigms and how to think in terms of a programmable editor.
---
[01:04:39](https://www.youtube.com/watch?v=VADudzQGvU8&t=3879s) Email Frustrations: Plain Text vs. HTML Formatting
Metzger voices deep personal frustration over his inability to rely on Emacs for modern email, despite being an avowed fanatic. While some users advocate for rich HTML emails with colors and proportional fonts, Metzger explains that his objection to HTML email is cultural rather than purely aesthetic. In his experience, modern graphical mail clients encourage lazy communication habits: users routinely top-post without reading the thread carefully, leaving two-thirds of specific questions unanswered because they quote the entire conversational history wholesale. Metzger notes that if users composed HTML emails within an Emacs buffer—interspersing thoughtful replies inline and adding clear diagrams—he would welcome it; the issue is the loss of structured, deliberate discourse.
---
[01:05:43](https://www.youtube.com/watch?v=VADudzQGvU8&t=3943s) Symbolics Keyboards, Concurrency, and Garbage Collection Realities
An audience member shares an anecdote about spending three years working on Symbolics Lisp machines as an undergraduate, praising the hardware and the keyboard's dedicated modifier keys—Shift, Control, Meta, Super, and Hyper. The excess of modifiers occasionally led to absurd chord combinations like Control-Meta-Shift-Hyper-X, prompting Metzger to joke: “This is what your nose is for. This is why you have a nose!”
Turning to technical runtime limitations, an audience member challenges Metzger’s earlier defense of the Emacs runtime, arguing that a modern runtime cannot simply ignore garbage collection (GC) pauses when introducing true asynchronous threading. Metzger clarifies his stance:
> “The garbage collector, in order to make in order to do the sort of thing that I’m talking about, probably has to get made a little bit thread-aware, though you can pull, however, garbage collectors that will do that off the shelf at this point; they’re even GPL.”
Metzger emphasizes that while a ground-up rewrite of the runtime sounds appealing to operating systems theorists, an outright replacement would break backward compatibility with thirty years of Emacs Lisp packages. The only viable path forward for Emacs is careful, incremental modernization that preserves the existing ecosystem while introducing non-blocking concurrency and thread-safe memory management.
[01:07:49](https://www.youtube.com/watch?v=VADudzQGvU8&t=4069s) Modernizing Emacs with LLVM and Closing Remarks
Perry Metzger reflects on how to modernize Emacs incrementally from "point A to point B" rather than attempting reckless, ground-up rewrites. Looking ahead to what could be done down the line, he points out that toolchains like LLVM have matured significantly and make building just-in-time (JIT) compilers straightforward. He envisions an architecture where developers could leverage LLVM infrastructure directly inside the editor to dynamically compile Emacs Lisp—or whatever language eventually succeeds it—into high-performance native code.
Poking fun at the endless wishlists of software developers, Metzger jokes about wanting a pony bundled in as well, quipping that someone could simply implement `M-x pony`. As the session draws to a close, he checks in with the audience to see if anyone has remaining questions or if it is time to wrap up. Seeing no further questions, he thanks the audience and the hosts at thoughtbot for having him, concluding his reflection on over three decades with the editor.
> “You could slurp the LLVM stuff in and you could JIT your Elisp, or your successor to Elisp.”
- **Evolutionary path over total rewrites:** Instead of scrapping Emacs, Metzger advocates incremental modernization to transition the editor from its legacy architecture to modern computing environments. - **LLVM-backed JIT compilation:** Modern compilation toolchains like LLVM offer practical frameworks to JIT compile Emacs Lisp or any prospective successor language. - **Humorous feature requests:** Metzger jokingly suggests adding `M-x pony` to the editor's command palette alongside cutting-edge compiler integration.
## Notable quotes > [56:22](https://www.youtube.com/watch?v=VADudzQGvU8&t=3382s) I don't care if you pick Emacs or vi, but you have to pick one of them, and the reason is because you need to have a text editing environment that you will be comfortable in for a very long time to come. — Perry Metzger
> [19:34](https://www.youtube.com/watch?v=VADudzQGvU8&t=1174s) Computer scientists also need their tools to be efficient; pretty is not a concern, getting your work done quickly is a concern. — Perry Metzger
> [15:48](https://www.youtube.com/watch?v=VADudzQGvU8&t=948s) TECO was a terrible extension language, but the fact that it existed was more important than that it was good, and in fact I would argue that in some sense that's the situation with Elisp today. — Perry Metzger
> [09:52](https://www.youtube.com/watch?v=VADudzQGvU8&t=592s) 1976 is the year Emacs shows up, 1976 is the year VI shows up. I do not see this as a coincidence at all; it was a response to the fact that the technology finally became possible. — Perry Metzger
## Mentioned Perry Metzger, thoughtbot, Emacs, vi, Richard Stallman, Guy Steele, Benjamin Pierce, Rob Pike, Brendan Eich, Nadeem Kobeissi, TECO, Emacs Lisp (Elisp), Common Lisp, JavaScript, LLVM, Clang, WebKit, CEDET, Proof General, Coq, NetBSD, TOPS-20, DEC VT100, DEC VT52, DEC-20, PDP-11, PDP-8, Space Cadet keyboard, Symbolics Lisp machine, IBM Model M, Kinesis Advantage, GNOME, Eclipse, Xcode, Epsilon, Unipress Software, University of Pennsylvania, MIT AI Lab
## Video description Perry Metzger has been using Emacs as his text editor since early September, 1983 -- nearly 31 years. Over much of that time, it has also been his primary way to read email, compile programs, and perform a variety of other tasks.
Why would anyone use a single program for that long? This talk is partially intended to answer that question.
Emacs remains one of the most important user interfaces (and text editors) for computer professionals almost 40 years after it was created. The talk is intended to be part history, part philosophy, and part speculation on the future. It will also teach Emacs fans how to explain to their skeptical friends why it is still a good idea to learn a tool from the terminal era that requires memorization of dozens of control sequences in an age of GUIs and smart phones.
Learn more from the developers at thoughtbot ⌨️ Head over to http://tbot.io/dev-blog to read more great articles on our blog.
[Source](https://www.youtube.com/watch?v=VADudzQGvU8)