Metzger Demands Emacs Add Threading, WebKit to Avert Obsolescence

The Editor of a Lifetime — thoughtbot

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)

中文简报

Metzger呼吁Emacs引入多线程与WebKit以避免被淘汰 Emacs之所以能留存至今,是因为键盘驱动的可编程性胜过了图形化IDE,但Metzger警告称,除非开发者在不针对轻度用户削减功能的前提下引入真正的并发、WebKit缓冲区并现代化运行时,否则该工具将面临被淘汰的风险。 Perry Metzger探讨了Emacs的长盛不衰,认为自1976年以来的生存是自然选择的结果,这种自然选择更青睐键盘驱动的编辑速度、极强的可扩展性以及类似于个性化操作系统的开放架构。他主张,软件从业者的整个职业生涯都在处理文本,因此与转瞬即逝的商业IDE相比,对一款适用终身且适应性强的工具进行高昂的前期投入是极其划算的。然而,为防止该编辑器陷入停滞,Metzger概述了必要的演进路径,包括克服其单线程运行时、整合如LLVM等具备编译器感知的工具,以及使Web和邮件协议现代化。在整个演讲与问答互动中,他强调只有社区在保持向后兼容的同时继续渐进式地现代化其底层基础,Emacs才能维持其生命力。 Emacs和vi在近四十年的计算技术变革中经受住了自然选择而幸存下来;它们诞生于1976年,当时串行视频终端首次实现了全屏位置光标控制。 (9:52) 熟练掌握Emacs需要两到四周的前期投入,但Perry Metzger认为,这笔成本能在数十年职业生涯中每天节省数分钟至数小时的编辑精力,带来无与伦比的回报。 (24:11) Emacs的单线程架构仍然是其主要的结构性瓶颈,在进行耗时的I/O或正则表达式计算时会导致整个缓冲区的UI冻结,并迫使高级用户同时并发运行多个实例。 (35:29) Metzger并不赞成推倒重来、丢弃30年积累软件包的做法,而是主张进行渐进式现代化改造,包括嵌入WebKit、在现有C运行时上并行运行现代化Lisp,以及采用LLVM进行语义解析和JIT编译。 (28:41)

Source quotes

[56:22] Perry Metzger: 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. [19:34] Perry Metzger: Computer scientists also need their tools to be efficient; pretty is not a concern, getting your work done quickly is a concern. [15:48] Perry Metzger: 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. [9:52] Perry Metzger: 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.

Original transcript

[0:01] [Music] [0:14] uh this is a version of a talk that I [0:16] actually gave last year on on on a more [0:19] momentous occasion which was when I [0:21] actually had been using emac for 30 [0:24] years I've now been using emac for 31 [0:27] years shy I guess of four weeks [0:30] uh or maybe even a little less than four [0:33] weeks um so uh good [0:36] evening paron can you go back can I go [0:40] back I'll give you my slides there the [0:43] the PDF works much better [0:47] tost okay post post it on social media [0:52] on the test yes as as it turns out [0:55] though I can give you the actual PDF # [0:58] ncx [1:00] yeah any to cut and paste a picture of [1:02] you and next to it very good anyway so [1:05] as I said I learned emac in September [1:08] 1983 and it's now August of [1:11] 2014 so it's about 31 years which is [1:15] which is kind of amazing to me uh why [1:19] would anyone use a program that long I I [1:23] won't say why would anyone in their [1:25] right mind use a program that long [1:27] because there might be some debate on [1:29] that question but why would anyone use a [1:32] program for that long I the [1:35] state-ofthe-art in in in in computer [1:37] systems has changed dramatically over [1:40] the course of time I mean this was the [1:44] the best terminal you could get your [1:46] hands on at Columbia when when when I [1:49] learned emac people people really really [1:53] fought to ah hold on people really [1:56] fought to get themselves uh you know [2:00] time on on a good VT 100 you know if you [2:03] were stuck on one of the Lear seagler [2:05] foxes you were really really unhappy you [2:08] know there there there were there were [2:10] some other you know things that were [2:11] considered decent but you know this was [2:13] like a real state-of-the-art user [2:15] interface for for emac in 1983 and [2:18] people would camp out to use them and [2:20] now you know if I owned one of these it [2:23] would probably be in in storage not in [2:26] my apartment yeah so that Columbia were [2:28] you at Columbia at the time yeah yes [2:30] okay I was there a decade later I was I [2:33] I I I was a freshman but anyway so best [2:37] best so this is the best thing you had [2:40] for using for using emac at the time and [2:44] the OS I was using and no we could take [2:47] questions later uh the operating system [2:50] I was using was tops 20 on a deck 20 and [2:53] this part of this photograph is approx [2:56] is one of those deck 20s uh you know [3:00] somewhat larger than my current [3:03] computer um you know not quite as [3:06] elegant no USB ports uh no USB ports I I [3:10] cannot say that I miss using the deck 20 [3:13] for all my work um you know aside from [3:17] Nostalgia and people who are really into [3:19] Retro Computing no one wants to use [3:21] Museum Hardware um some of you in this [3:24] room looking around I I I wrote this on [3:27] the assumption but I'm pretty sure we're [3:29] not born in [3:32] 1983 um okay so why the hell would I [3:37] still be using [3:39] emac uh in fact I I don't just use emac [3:44] vaguely uh I only recently stopped using [3:46] it for reading email uh and and the [3:49] reason I stopped using it for reading [3:51] email was that it that IM at support and [3:53] a couple of the the built-in mail [3:54] readers is just too crappy and and HTML [3:58] support is a little bit too crappy I [4:00] will be discussing that towards the end [4:02] of the talk uh but anyway we we we [4:04] should fix that but and I certainly [4:06] intend to use it for for reading mail [4:08] again I keep my calendar and my phone [4:11] book in emac although I'd like better [4:14] local OS integration it's still seems to [4:16] be the best way for me to do this stuff [4:19] uh I do all my development work in emac [4:22] uh I sometimes use emac for chat if I'm [4:26] doing chat I generally do chat in emac [4:30] uh I wrote this presentation in [4:33] emac uh It Was Written in latek uh I [4:37] wish I could browse the web and read [4:38] papers in emac we will discuss that [4:41] topic more later uh and I'm not the only [4:44] lunatic it turns out uh there's another [4:48] PhD student at Penn who I won't name who [4:51] said to me that he really D you know I [4:54] asked him basically why was he content [4:57] to use a particular revolting operating [4:59] system on his laptop and he said I don't [5:01] care it's just a Bootloader for [5:04] emac um so if you happen to take the you [5:08] see now the the origins of this talk in [5:11] a talk that I gave at pen if you take uh [5:14] CIS 500 uh you know Professor Benjamin [5:17] Pierce spends most of the lectures [5:20] running proof General inside emac uh to [5:24] show you know the proofs that he's doing [5:26] inside cook inside proof General inside [5:29] emac [5:30] uh I have a a completely apparently [5:33] normal friend he seems normal at least [5:36] he is non- technical he does not do you [5:40] know he doesn't know how to program he [5:42] uses emac for his calendar his to-do [5:44] list for editing text he uses it for [5:46] practically everything I am giving this [5:49] talk to a group called an emac Meetup [5:52] why would anyone to have an editor [5:56] Meetup um I gave this the original [5:59] version of this talk to the emac club at [6:03] pen now there are a lot of weird people [6:05] in any computer science department but [6:07] at Penn there is an emac [6:10] Club so point out they also win the ACM [6:13] programming contest quite office but [6:16] that's that's partially that's partially [6:18] because of the high concentration of PL [6:20] people who are really really godamn [6:22] brilliant partially because they like [6:24] using emac um there's an emac Meetup [6:27] here in a city where you could do [6:30] so many things with your evening there's [6:32] an endless number of things you could [6:35] name one I you know I'm drawing a blank [6:38] right now but I'm sure there's something [6:40] therey meet up tonight I think there you [6:43] go you could have gone to a python meet [6:45] up you know there are probably no less [6:48] than a couple hundred Live musical [6:50] performances that are decent that you [6:52] could be going to this evening and here [6:54] you are listening to a middle-aged man [6:57] talk about a text editor [7:01] sorry great thank you yes yes I I I [7:06] suspect that that that's not entirely [7:08] perfect in directionality but anyway so [7:10] there's an emac Meetup here you know [7:14] this implies s some sort of fanaticism [7:18] no reason yes in any case why you know [7:23] is it because emac is so easy to [7:26] learn um and and and and and you know we [7:30] all know no it is not easy to learn only [7:32] because the tutorial is broken sorry uh [7:35] and and is it the prettiest editor you [7:38] have ever used um no [7:43] um uh sorry uh so anyway uh damn it I'm [7:51] getting keyboard bounce on this anyway [7:55] is it because emac is so well marketed [7:59] and and and everyone remembers that in [8:02] fact unipress tried to Market [8:05] emac and and and and everyone knows what [8:08] a great commercial success unipress is [8:11] to this day right I I I I don't think [8:13] you can even find any information online [8:16] anymore about what happened to them it's [8:19] that you know that it it happened that [8:21] long ago uh on the other hand I know [8:25] people who like don't understand why you [8:27] would want to touch this thing with a [8:29] 10-ft pole uh I've got a doctoral [8:32] brother who uses an [8:34] IDE uh I have uh you know and and and I [8:38] don't think he's ever even tried emac [8:40] maybe he was told about it and he [8:42] thought that the people telling him [8:43] about it had to be nuts um you know [8:47] there are a couple of VI users in my lab [8:49] I I respect them you know that's it's it [8:51] it it you know I'll I'll talk about why [8:53] I respect them in a little bit um I I [8:57] have the occasional student student who [9:00] who when I've been when I've been [9:01] teaching who's shown up for office hours [9:05] and and and it has turned out that they [9:07] were using something like like like you [9:12] know like like the the [9:16] builtin Microsoft text editor or or or [9:20] maybe notepad++ which is apparently some [9:24] really extended version of notepad um [9:28] you know and and I've looked at them and [9:30] wondered you know about about them but [9:32] never mind you know there are all these [9:33] people out there that don't get why you [9:35] would want to learn emac so why you know [9:39] is it just mental illness and the answer [9:42] is no it's not just mental [9:46] illness [9:48] um well F first the the uninteresting [9:52] explanation and now the clicker won't go [9:54] forward this is good ah there we go uh [9:58] natural selection and I'm quite serious [10:00] about this so everyone remembers using [10:04] these right uh yes several of us [10:07] remember using these the first machine [10:08] that I used 114 [10:12] 1145 that would have been luxury sheer [10:15] luxury I I worked the gentleman mentions [10:18] that he was working on a pdp1 under [10:20] risus I was using a pdp8 under os8 which [10:25] was a substantially more constrained [10:27] environment um [10:31] pardon anyway we you know we we couldn't [10:34] afford an 11 you know but anyway so so [10:37] this is this was up until the mid [10:41] 1970s the state-ofthe-art [10:43] in uh in in in interfaces to a [10:48] computer and when you used a teletype [10:51] you used a line editor because what else [10:55] could you possibly use and and in the [10:58] late 19 60s glass TTY started showing up [11:03] which were a tremendous Improvement [11:05] because they saved paper but you know [11:07] had the problem that you know you [11:08] couldn't just you know look back on the [11:10] paper to see what you've been doing a [11:11] couple of minutes before but by the mid1 [11:13] 1970s this miraculous new thing happened [11:17] there were commercial serial terminals [11:20] uh you know full screen with positional [11:23] cursor control like the [11:26] vt52 and I don't think that it's a that [11:30] that what happened is a coincidence we [11:32] had line editors around by [11:35] 1975 terminals are highly established [11:39] 1976 is the year emac shows up 1976 is [11:43] the year VI shows up I do not see this [11:46] as a coincidence at all it was a [11:48] response to the fact that the technology [11:50] finally became possible um now the thing [11:54] is that there were at least hundreds of [11:56] screen editors created during this [11:58] period you know huge huge numbers of [12:01] them and there are only two survivors [12:04] one is VI and one is [12:06] emac and I think that they probably [12:10] survived not be you know necessarily you [12:13] know it you know because they're they're [12:17] you know they're not necessarily the [12:18] best of the lot from that era but [12:20] they're probably you know ones that [12:22] people fell in love with so hard that [12:25] they really really insisted on keeping [12:27] the things around um they also had [12:30] structure editors there there were well [12:32] there were all sorts of interesting [12:34] things from the era you know yes people [12:36] built structure editors they built they [12:38] built they built all sorts of things but [12:42] uh so the question is were the designers [12:43] lucky or [12:45] smart uh there's no real way to answer [12:47] this definitively but I would argue that [12:50] the designers of emac were pretty smart [12:53] uh it wasn't the First full screen [12:55] editor they dealt with they'd had some [12:57] experience over the course of the [12:59] previous year couple of years with some [13:01] others uh including e Tio's control R [13:06] mode which is best [13:07] forgotten um and uh and and and stalman [13:12] and uh and and steel and others began to [13:14] improve too and and and and add macro [13:18] packages to it uh the macros evolved [13:21] fast because every the source to [13:23] everything was available and people were [13:26] constantly hacking on it uh the [13:28] community that it evolved in had very [13:30] very good hackers and you know and it [13:34] and it changed very fast but in some [13:35] sense it doesn't make any [13:37] difference um whether it was it was you [13:40] know Brilliance or the accident on [13:42] hitting on the right design it seems to [13:44] be the right [13:45] design um it works really well um you [13:52] know menus and mice are just too slow if [13:56] you're trying to edit stuff um uh and [13:59] and as I'll mention you know that's what [14:01] most of the people in this room do for a [14:03] living we we write things for a living [14:06] uh and in emac you can change text as [14:09] fast as you think uh the keyboard [14:11] orientation is a serious feature uh [14:15] because the hands never leaving the [14:17] keyboard means speed you know you can [14:20] open and close files and and you know [14:23] and and and switch between buffers and [14:25] do all sorts of things without ever [14:27] having your cans move leave the keyboard [14:31] uh there are huge numbers of features [14:33] for programmers you know everything from [14:36] you know from indentation to you know to [14:39] to compiling your code to running your [14:42] code to debugging your code you know [14:45] without having to have your hands [14:48] move um and and you can do Mass edits uh [14:53] without even doing terribly much [14:54] programming thanks to the macro facility [14:57] um it is difficult to to explain to [14:59] people who' have not used emac for a [15:00] long time how you become come to depend [15:04] on it you know you're typing along and [15:07] you type two letters [15:09] transposed and if you were using a [15:11] normal editor when you got halfway down [15:14] the line and notice that the fact that [15:16] they were transposed you would move your [15:19] finger and you would you know and and [15:21] you'd click there and you hit delete a [15:24] couple of times and type it and in emac [15:26] you hit contrl T you know I this this [15:29] sort of thing is is is transformative [15:32] it's different uh editing in GUI [15:35] drags uh editing you know when you have [15:37] a keyboard from which you can control [15:40] everything is really fast and many of [15:41] you I see in the audience are nodding [15:43] your head those of you that are still [15:44] awake of course um it's also extensible [15:49] which is really damn important too was a [15:51] terrible extension language but the fact [15:53] that it existed was more important than [15:56] that it was good and in fact I would [15:58] argue that in some sense that's the [16:00] situation with elisp today um so lisp [16:03] ended up becoming a customary extension [16:06] language after you know too died gimax [16:09] being the thing that everyone is used to [16:11] using to this day with elisp uh [16:15] extensible means that you get [16:17] extensions uh you can read your mail in [16:19] emac you can run the debugger in emac [16:21] you can you have Ides in emac you have [16:24] refactoring tools in emac and and of [16:27] course if you find yourself needing to [16:29] do something in to to edit and the [16:32] people who had created the editor didn't [16:34] think that you might want it unlik you [16:36] know if you're using X code you're what [16:38] can you do you can't you know you don't [16:40] you can't change the editor you're using [16:42] emac you just you know you know if a [16:45] macro won't do you write a little list [16:46] code you throw it into your init and [16:49] there you're done um [16:52] extensions are applications and in some [16:55] sense what emac is is a user interface [16:58] for producing applications in which [17:00] editing is part of the [17:02] application um so but why write [17:06] applications in a really mediocre [17:08] language like elisp um extensions seem [17:12] like a really weird thing to non- emers [17:15] why would you want to read your and and [17:17] and write your email inside of your text [17:20] editor and and the answer is because [17:22] it's natural when you're writing email [17:25] you're editing text and I find myself [17:28] face all the time these days when I'm [17:30] when I'm corresponding with people who [17:32] are using Outlook as their as their [17:35] interface for for reading and writing [17:37] email they're not really able to [17:40] manipulate text well enough to give [17:42] meaningful responses to your email you [17:45] know you'd like them to do the standard [17:48] you know quoting style that that that [17:49] that oldtimers like where they go [17:51] through the email and they respond Point [17:53] by point to the eight things that you [17:55] gave them but instead because they're [17:57] writing an Outlook or even worse because [18:00] they're writing inside an email [18:02] application on their iPhone um all they [18:05] can do is respond with two lines uh of [18:08] not particularly well written text so [18:11] why would you want to to write your [18:13] email inside of a text editor so that [18:15] you can write email and have it be [18:18] reasonable you know reasonable [18:20] interesting well-written text um so I've [18:25] heard people say this all the time to me [18:28] over over the decades you know emac is [18:31] an operating system you know it's too [18:33] big it's it's it's it's too vast you [18:36] know why would I want to run another [18:39] operating system and and my reply to [18:42] that is you say that it's an operating [18:43] system like that's a bad thing it's not [18:46] a bad thing it's a good thing in fact I [18:48] would argue very strongly that it is not [18:52] enough of an operating system and [18:54] towards the end you know towards the [18:56] second half of my talk I'm going to talk [18:58] about why uh I think that is and and [19:01] what we should do to make it more of an [19:03] OS uh it's more of a UI framework than a [19:05] true operating system at the moment um [19:08] here is a a fine joke I just had to [19:11] include I hacked on netbsd for for a [19:14] very very long time and when I redid the [19:16] bootloader I put this code in which [19:19] unfortunately someone without a sense of [19:21] humor removed a couple of years ago oh [19:26] um but you know at at at at some some [19:28] point you know they won't be looking and [19:31] I'll put it back um anyway so yes emac [19:35] is a UI for for hacking on large amounts [19:38] of text why wouldn't you want to be able [19:40] to cut and paste from other files with [19:42] the keyboard while composing mail you [19:44] wanted be able to write mail fast you [19:46] want your mail messages to look good why [19:48] wouldn't you want to be able to edit and [19:50] debug inside the same application and [19:53] this is an idea that is powerful enough [19:55] that it got adopted by all of the [19:57] world's idees and you know you run [19:59] something like xcode or or or or you [20:02] know the the Microsoft Visual blight [20:05] line and uh and and and and you have an [20:08] IDE now in which you can debug in the [20:10] same application but but you can't [20:13] reprogram uh your your IDE uh when [20:17] you're using something like xcode or or [20:19] visual C++ the way that you can emac um [20:23] why wouldn't you want to reprogram and [20:25] extend your user interface especially if [20:28] you're a computer scientist you know and [20:31] and this is a point I want to make good [20:32] computer professionals make tools for [20:34] themselves to use now there there are [20:37] other professions that have a precedent [20:39] on this machinists spend a large [20:41] fraction of their time making tools for [20:44] themselves modifying their Tools in [20:46] order to be able to achieve the kinds of [20:49] part configurations that they want to be [20:51] able to achieve them in a reasonable [20:53] period of time good Prof computer [20:56] professionals do exactly the same thing [20:58] we know how to program we find ourselves [21:01] with tasks that are well suited towards [21:05] writing a program in order to do them it [21:08] makes our lives [21:09] better when we write improvements to our [21:12] own tools or create new tools so why [21:15] wouldn't we spend a large fraction of [21:16] our time doing it in fact you know that [21:18] I know at least one person in the [21:20] audience tonight has as his job he works [21:23] on maintaining the programming [21:25] environment for other programmers at a [21:27] at a big shop this is a job people have [21:31] you know tool smithing maintaining [21:33] maintaining environments and of course [21:34] programmers routinely do all of this [21:35] sort of thing for themselves even at [21:38] places where there are other people who [21:39] help them that way um emac is portable [21:43] and open source and this is this is a [21:45] really significant feature non-portable [21:48] programs die with the system that they [21:51] that they were born on um closed Source [21:54] programs die with the company that built [21:56] them you know over the years I have seen [21:59] editor after editor that you know that [22:01] you know I've had people tell me oh why [22:02] aren't you using you know this random [22:05] piece of code and if I'd been using that [22:07] that editor I would have had to stop [22:09] using it many many years ago when the [22:10] company died or merged and the product [22:13] was dropped or what have you um but emac [22:17] is open source and once it was ported to [22:20] C and Unix you know the only thing that [22:23] can stop people from using emac is if [22:25] they decide that they're no longer [22:26] interested the the of the system they're [22:29] running on the the death of the company [22:32] that provides the editor these are not [22:34] concerns so the result of this is that [22:37] you can learn a powerful system once and [22:40] then use it for decades um and this is a [22:44] point that a side point that I wanted to [22:47] make which is that professionals don't [22:49] really care about pretty in their tools [22:52] how many people here have seen a [22:53] restaurant kitchen or have worked inside [22:56] one for any period of time we have a [22:58] couple of people for those that if you [23:00] have a chance ever peek inside [23:03] one that you will not find granite [23:08] countertops you will not find you know [23:11] beautiful stained oak cabinets that were [23:14] handmade um in fact you're not even [23:17] going to find you know the the the the [23:19] high-end expensive Viking Range that [23:23] that your wealthy friend had installed [23:24] in his house with a beautiful red enamel [23:27] because they don't care about about that [23:29] you know people that work in restaurant [23:31] kitchens need to prepare hundreds of [23:34] dinners in a night and they don't have [23:36] time to screw around they don't care [23:38] about pretty they care about efficient [23:40] efficient is the only thing that they [23:42] care about computer scientists also need [23:46] their tools to be efficient pretty is [23:48] not a concern getting your work done [23:51] quickly is a concern you're not being [23:53] paid you know to have a beautiful [23:55] experience you're being paid to get [23:57] something out the door um and editing [24:01] text is what computer scientists do for [24:03] a living and we do only two things we [24:07] read text we write text and in fact no [24:11] one pays us to read if we're not then [24:14] writing something after we've read up on [24:17] how to do it so we had a text for a [24:20] living and and whether it's [24:22] documentation or web pages or software [24:25] or systems Administration utilities or [24:28] what have you we spend all of our days [24:30] editing text so your productivity as a [24:33] programmer as a systems administrator [24:35] Etc depends on how efficiently you edit [24:38] text so it shouldn't be surprising that [24:41] we care most about the efficiency of the [24:44] tool with which we edit text and and a [24:46] whole lot less about whether it has [24:48] really pretty icons that that were done [24:51] you know in a vector drawing program and [24:53] have nice Blended shading on them or [24:56] what have you animations and animations [25:00] yes yes that's that is a good point [25:02] without animations what can you do [25:04] anyway endurance is also a feature here [25:07] to be productive you have to learn how [25:09] to use your editor well it is not enough [25:12] just to you know I mean if if you didn't [25:13] need to use it well you know then then [25:16] you know then certainly you know [25:17] wouldn't you know wouldn't uh notepad be [25:20] enough for writing large pieces of [25:22] software um and I've had to learn just [25:25] one editor well for most of my career [25:28] um you know I've been able to use it for [25:31] over 30 Years it'll probably be around [25:33] for another 30 years until I drop dead [25:37] uh probably I'll drop dead before [25:38] another 30 years pass but never mind um [25:42] so it's okay that uh that that that it [25:46] takes a long time to learn how to use it [25:50] because there's enough time if you can [25:52] use the thing for decades for the [25:54] investment to pay off uh it took me a [25:57] couple weeks to get really good with [26:00] emac uh maybe a month before I was [26:02] really sailing without thinking about it [26:05] but over the last several decades it [26:07] saved me a few minutes to sometimes a [26:09] couple of hours every single day of my [26:13] life this is an amazing return on [26:16] investment you know this is this is you [26:18] know this is a fine fine thing so why [26:22] has emac survived it's because it's a [26:24] great editor that you can practically [26:26] live in you can do everything inside it [26:29] uh you can extend it you can customize [26:31] it so if it doesn't do something you [26:32] want you can make it do it uh you will [26:35] never have to stop using it because it's [26:37] open source and and can be ported to [26:39] almost anything and if you're a computer [26:41] professional that's irresistible and [26:44] that's why there are Fanatics in this [26:46] world and that's why we find ourselves [26:48] at an emac [26:50] Meetup so what could result in emac [26:54] dying um failing to adapt I think [26:58] uh now emx has to to for the most part [27:01] actually adapted uh it's changed [27:04] significantly over its 38-year life span [27:07] it has a much improved extension [27:08] language over what it started with it [27:11] now has Windows system support no one [27:12] runs emac on a vt100 anymore people run [27:16] emac Windows inside their GUI sometimes [27:19] inside the terminal emulator in their [27:21] GUI because they're running over SS or [27:24] what have you but but you know mostly [27:26] people run it you know rund direct [27:28] windows in their GUI it's got vast [27:31] numbers of new modes it's got you know [27:33] it can do networking it can do all sorts [27:34] of things it couldn't do before but I [27:37] claim it needs to go further uh the [27:40] extension language is still mediocre and [27:42] this has become an increasing problem [27:44] because people want to be able to write [27:46] larger and more interesting applications [27:48] in it the extension language is kind of [27:50] crappy um uh the what do you mean by the [27:53] extension youan Elis I mean Elis um the [27:56] word that should not be mentioned elisp [27:58] is a fine word it's it's it's it's it's [28:01] it's don't you think that Comm support [28:02] though is taking it a little bit we'll [28:04] get to this um we need better support [28:08] for refactoring and and and and modern [28:12] programming uh tasks um this is doable [28:15] we'll get to that in a couple of minutes [28:17] it's not enough of an operating system [28:19] in my opinion in particular the [28:21] threading sucks we'll talk about that um [28:25] it's not enough of an operating system [28:27] because I still need need to leave it [28:29] here and there which is a problem and I [28:31] think it needs more integration with [28:33] things like personal information [28:34] managers and other kinds of protocols [28:36] that people care about today we'll get [28:38] to that briefly so anyway suggestions on [28:41] future proofing emac so anyway too was [28:45] not really a pretty [28:48] language uh unfortunately this cut off [28:52] it goes on a little bit further over [28:54] there uh does does now how many people [28:57] in the room can tell me what this TCO [28:59] code [29:00] does it's part of the correction for the [29:02] Y2K problem [29:05] no a good guess this this too code [29:09] calculates the digits of [29:13] pi and it should be obvious to anyone [29:16] looking at it anybody knows that it [29:18] calculates the digits of pi to was is is [29:21] such an awful language that that a [29:24] popular game apparently used to be [29:26] guessing what someone's name name would [29:28] do if entered in as a too [29:33] program and so elisp in spite of of of [29:37] of the problems that it's got was a [29:38] fairly big Improvement but unfortunately [29:42] elisp still more still kind of sucks uh [29:45] some improvements have been made to Elis [29:47] of late it finally has lexical scope if [29:50] you ask for it uh if you ask for it um [29:55] but on the other hand the API the Legacy [29:58] emac apis if you've done any hacking in [30:01] in emac are kind of awful stuff has [30:04] accreted you know over the years without [30:07] any rational design on on all sorts of [30:09] stuff there are no real modules there [30:11] are no name [30:13] spaces um this is a serious problem [30:16] there's no threading the lack of [30:19] threading is actually an issue I don't [30:22] want as I'll get to I don't want [30:25] necessarily the most General threading [30:26] on Earth but but but but I but what [30:29] we've got right now is is way [30:31] insufficient it's not really a good lisp [30:34] by modern standards um why a common list [30:38] well anyway I think that it should it [30:40] needs to be replaced I mean when I [30:42] program em I program common list yes but [30:45] anyway my solution to this is to is to [30:48] build a better Lis in parallel and what [30:50] do I mean by this so there are lots and [30:53] lots of people out there I'll give a a a [30:55] an example which isn't really quite on [30:58] on you know on point and then and then [31:01] and then move to what I really mean [31:03] there are lots of people out there now [31:04] that are using languages that are based [31:05] on the jvm that are not [31:08] Java uh and many of them are much much [31:10] better than Java in fact it's difficult [31:13] to imagine one that anyone would use [31:15] that would be worse than Java um but [31:18] anyway there there are a number of of [31:21] languages and they can take advantage of [31:22] the Java infrastructure by being based [31:25] on the jvm without having to throw all [31:28] of that infrastructure out and you can [31:30] argue whether this is a good idea or a [31:32] bad idea but for a lot of people this [31:34] has been very appealing I would argue [31:37] that we have a perfectly good language [31:39] runtime inside The emac [31:43] Interpreter it's true to a first [31:45] approximation I would not call it the [31:47] best language runtime but it's it's it's [31:49] good enough okay there's all of this [31:51] code that runs in this runtime already [31:55] uh the runtime provides lots and lots of [31:57] data structures uh like buffers that one [32:00] wants in one's editor one could build a [32:03] second list in parallel that use the [32:07] same runtime and unlike the jvm [32:09] situation one is allowed to improve the [32:11] runtime or add extra features to it [32:15] while one is so long as it doesn't break [32:17] the old code while one is improving the [32:20] system I I would argue that this is [32:22] probably a profitable way to go one [32:25] could design a a new list that had [32:28] actual modules name spaces [32:31] Etc uh that had access to the other [32:34] lisps name space and could call into it [32:37] uh and then could provide new non- [32:39] Legacy non- revolting apis for for for [32:43] doing all of the things that emac [32:45] provides and and that would from the [32:47] start have support for lexical scoping [32:51] and and more modern common Lis be style [32:54] features Etc you you keep pointing in my [32:57] general direction [32:58] later I'll range yes why do you think [33:00] that this is better than using common [33:01] list and one the issues I have I'm not [33:02] saying common list is necessarily a bad [33:04] idea okay okay because I just have a [33:05] problem people keep inventing you lisps [33:07] it just fractures the community and [33:09] fragments things you know I'm I'm [33:12] somewhat agnostic about that but we can [33:13] yell about it during The Question period [33:15] I assume I'll have time for questions uh [33:18] anyway uh second thing um better tools [33:23] inside emac for the programmer uh [33:26] eclipse code Etc are are aware of all [33:30] the symbols in your program there are [33:32] some tools inside emac like like cedit [33:35] and what have you that that have those [33:38] capabilities but they're kind of ad hoc [33:40] and not particularly great we need [33:42] better uh xcode and some of the other [33:45] things here now use [33:48] llvm's tools to provide there are code [33:52] parsing and code walking and simple [33:55] table access and there's no reason emac [33:58] couldn't do and that would eliminate the [34:01] need to try to reinvent the square wheel [34:04] when there are fine Square Wheels [34:05] available for purchase on the open [34:07] market um I think that this is probably [34:09] the most profitable line for people to [34:13] to go that way in and it would make it a [34:15] whole lot easier to build refactoring [34:17] tools for things like C++ uh and and and [34:20] you know and and and things like symbol [34:23] completion and what have you um by [34:25] actually making use of of of the the [34:27] actual compiler infrastructure a better [34:30] extension language would also help a lot [34:32] here um trying to build tools for some [34:35] of this stuff in Elis it's a little bit [34:37] painful um threading yeah this has been [34:41] an irritant for me for years emac blocks [34:44] all windows when you are doing [34:46] computation in any window it it's an [34:50] operating system but it's not enough of [34:52] an operating system I myself find you [34:55] know will'll run three or more inst of [34:58] emac on my desktop to get around this [35:00] I'm you know I'm slurping in my email [35:03] and I can't do something else at the [35:04] same time because it's often space [35:07] slurping in my email it's it's going [35:10] through and it's doing some you know it [35:12] wants to do some sort of extended [35:13] computation I can't go into another [35:16] window and do anything else at the same [35:18] time this is irritating name compilation [35:21] Windows pardon why aren't you running [35:23] named compile mode Windows uh even if I [35:25] have a named compile mode window if [35:27] you're if you're in something like news [35:29] and it's going off and doing something [35:31] it blocks you it if it's doing an [35:34] extended computation and doing a lot of [35:35] file.io and talking to the network it [35:37] blocks you there's not more than one [35:39] sorry there's not more than one thread [35:41] there we're exting a regular expression [35:43] over a large buffer over and over again [35:44] I just want to go to another buffer [35:46] right yeah and and and and it would be [35:50] nice to have that [35:52] capability um and and and right now you [35:55] know you don't have it and it means that [35:57] some of us end up running multiple emac [35:59] instances in spite of the fact that [36:01] really for maximum fun you only want to [36:03] run one emac [36:05] instance my vague thought on this and [36:07] people have been working on this [36:09] half-heartedly for years is maybe the [36:11] solution is to bind threads to [36:14] buffers and and to have buffer and [36:17] thread [36:18] local um data and to only need to lock [36:22] global data and there isn't that much [36:24] global data that you're that you're [36:26] accessing typically so the performance [36:28] hit is not going to be particularly [36:29] large even though locks I don't think [36:32] will be the problem I think the problem [36:33] you have as you're talking about thread [36:35] which apparently would be useful have to [36:37] have a very limited stack size talking [36:39] list that burns not if you're using [36:41] spaghetti Stacks or something similar um [36:44] you do not need to use you do not need [36:47] to use statically allocated Stacks you [36:50] can use uh you can allocate stacks on [36:53] the Heap there are all sorts of of [36:54] mechanisms for doing this set is can set [36:57] up for it's not currently set up for [36:59] that but I've been proposing [37:00] constructing a new language possibly [37:02] anyway um so I'm confused by this I've [37:05] run common processes for hours doing [37:08] intense computations as as inferiors yes [37:12] right yeah it's not locking yeah if [37:15] you're running something inside Elis I [37:18] got it it blocks I got it okay yes you [37:20] can you can run it you can run stuff [37:22] forever in a subprocess so here's a [37:26] stupid suggestion just build a proper [37:28] conduit to an inferior Elis [37:31] interpreter well but but but the problem [37:34] then is but the problem then is that you [37:35] want to share data between them right I [37:38] said that's what that's what my know [37:40] proper conduit with but it's they're all [37:42] the same they it's super fit anyway um [37:45] so let's see my number one problem [37:48] however these days and this is a very [37:50] serious one is I find myself leaving [37:52] emac more and more and this is [37:55] irritating I leave emac most to browse [37:58] the web or to view HTML emails and in [38:01] fact these days I get so much HTML email [38:05] yes ji is growling and and he should be [38:07] but but it you know we don't have [38:09] control over over other people's [38:11] behavior as much as we would like you [38:13] know someday when I am dictator many of [38:16] you will will not may be happy and many [38:19] of you may be extremely unhappy but but [38:22] but we don't really have the ability to [38:24] do that sort of thing right now um [38:28] so my solution is again give into the [38:30] operating system impulse and embed [38:34] webkit inside emac well you want get a [38:37] few more system calls to go before it [38:38] can do everything that Unix does well it [38:41] can emac can already run many system [38:44] calls but that's not the point HTML [38:47] rendering is an extremely specialized [38:50] difficult people have tried building [38:51] HTML renderers inside emac and it's it's [38:55] just too much work keeping up with it [38:58] why keeping up with it when there are [38:59] people that are maintaining HTML [39:02] rendering libraries that you can just [39:04] use um so my notion is you render Pages [39:07] directly in emac Windows the UI is [39:10] managed by emac the buffer would be sh [39:13] it would be shared between emac and [39:15] webkit so you could do things like I [39:18] searching in web pages copying regions [39:21] from web pages and pasting them into [39:23] emails and such I have seen people look [39:26] at doing web kit by running [39:29] subprocesses where which render into [39:32] into windows that are not really part of [39:34] vac and you don't really get that that [39:36] way I think you really have to bite the [39:38] bullet and swallow it in and besides [39:41] this will return us to the old days [39:43] where emac was too large and and and [39:46] took up most of the resources on the [39:47] machine you know nowadays people say [39:50] nowadays people say8 Megs and constantly [39:53] swapping no of course you're not [39:54] constantly swapping not when you have [39:56] gigabytes [39:57] and gab of main memory but with with by [40:00] bringing webkit in we can get ourselves [40:04] back to the point where emac is actually [40:06] using most of the machine's resources [40:08] again which I think is important that's [40:10] okay now that's okay now we get a [40:12] computer to build company build a thing [40:14] that just runs emac and nothing but emac [40:16] we'll see um anyway uh similarly I I [40:20] really want a PDF viewer and and inside [40:23] and I want to be able to walk the PDF [40:25] and cut and paste from it and put it [40:27] into other things uh I I spend a lot of [40:29] my time writing documents which are [40:31] going to end up as PDFs and I want to [40:33] view them in parallel I spend other [40:35] parts of my time reading people's papers [40:37] and trying to quote from them or or [40:39] things like that this would be a [40:40] pleasant thing to do um I'd love to be [40:43] able to I search through a PDF uh you [40:46] know in fact I'd love for someone to [40:48] just put regular expression search into [40:51] Chrome why is it that no web browser has [40:57] I during the during the question and [40:59] answer um yes won't like the answer I'm [41:03] sure I won't like the answer anyway with [41:07] embedded webkit embedded PDF viewing I [41:10] may never need to leave emac anymore and [41:13] that would be pleasant uh you know [41:15] return to the way things were a few [41:17] years ago you know that'll that'll be [41:20] good um I'd also like better integration [41:23] with certain sorts of modern tools I [41:26] want the calendar modes to talk [41:28] calav uh I I want the mail readers to [41:32] really do IMAP and because you know the [41:35] average person now has many different [41:37] mail stores and the thing that drove me [41:39] off of reading my mail in emac was the [41:41] fact that I need to be able to read it [41:43] on the phone and I needed to be able to [41:45] read it on several different computers [41:47] which means IMAP is the right thing um [41:51] you know I I I really want you know [41:53] right now I have an Adcock contacts mode [41:56] and it's my fault for not having written [41:57] card DAV support for it but but but you [42:00] know it it it would be useful to have [42:03] something like that so basically this [42:05] goes back to to the same request for [42:07] more integration uh to be more of an [42:09] operating system and and and to provide [42:12] less excuses to leave the thing um I [42:16] suppose fewer excuses yes yes I I could [42:20] tell that there was someone in the [42:21] audience I could feel that someone in [42:23] the audience was [42:25] upset wasn't the only one there you go [42:28] um anyway a quick rant about [42:32] keyboards before we get to the end of [42:34] this discussion now now this is an older [42:39] Mac keyboard and you will notice that we [42:41] have control option and command on both [42:46] sides of the keyboard now I know there [42:48] are a lot of people here who because [42:49] they got used to control being there in [42:52] in the depths of time prefer control [42:54] there but I actually like being able to [42:57] touch type all my control keys and I [43:00] like having all my shift keys and [43:02] control keys symmetric on both sides of [43:05] the keyboard and if you buy even a [43:07] relatively crappy PC keyboard you mostly [43:10] have that these days however U on a Mac [43:16] modern Mac keyboards have removed the [43:19] control [43:20] key from the right side of the keyboard [43:24] and and and and and this inspired me [43:27] recently to get even more broadly upset [43:31] so many of you probably cannot read this [43:33] very well but this is a space cadet [43:35] keyboard a proper keyboard it's actually [43:38] not literally a space cadet keyboard I [43:40] believe this is a symbolics keyboard but [43:41] it's close enough to a space cadat [43:43] keyboard This is a keyboard that is [43:46] actually built for programmers now I [43:49] spend a bunch of my time using systems [43:53] in which Unicode math symbols turn out [43:56] to be very very helpful things to have [43:58] around uh and it's kind of weird that we [44:01] as programmers are restricted to a [44:04] vocabulary based on what you could fit [44:07] in a seven bit code in the mid1 1960s [44:11] you know being able to do for all and [44:13] and and and there exists and and having [44:16] various kinds of arrows is kind of nice [44:18] having Greek letters around is kind of [44:20] nice on this keyboard of course you [44:23] press Greek or front or top and you get [44:27] a very very wide variety of keys if you [44:31] want an uppercase Lambda you hit Greek [44:34] shift L and you get an uppercase L like [44:37] you should that's right what are the [44:40] Roman numerals do uh I I I think those [44:43] were were used for basically for [44:45] selecting UI things if you had a menu [44:48] pop up the first four things always [44:50] corresponded to the first four Roman [44:52] numerals people turned out not to use [44:54] that much so it got dropped from later [44:55] symbolic keyboards [44:57] um this keyboard is way over the top I [45:00] don't necessarily want this far over the [45:02] top though though I don't mind having [45:04] super you know hyper and Hyper and a [45:07] proper meta key and and maybe and maybe [45:10] a proper I'd like a proper compose key [45:12] so I can hit equals and Slash and have [45:14] that be not equals so so I don't quite [45:16] have to do everything off the keyboard [45:19] but but I want a keyboard somewhat like [45:21] this and and I've been thinking recently [45:24] you know we finally live in an era where [45:26] you can where you can Kickstart Hardware [45:28] projects right and and and so I've been [45:31] vaguely thinking of doing that how many [45:32] of you are crazy enough that if a [45:35] keyboard like yeah several of you take [45:37] my [45:38] money just put a track point on uh uh [45:41] you know if you can if you can find me a [45:43] supplier for the component uh and it'll [45:46] work just soldered onto a motherboard [45:48] then then then sure a track point would [45:50] be fine or the 10 of you want I have 10 [45:53] model M keyboards IBM well that's not to [45:57] supply a a large number of people but I [46:00] know there are people here who really [46:02] really love the buckling spring keyboard [46:04] unfortunately I think to this day [46:06] there's there you still can't get those [46:08] keys commercially you can get you can [46:10] get the keyboards commercially but you [46:12] cannot get the keys because they're not [46:14] individual keys they're molded as a as a [46:16] whole thing yeah well anyway ask me [46:19] later yes um so anyway uh I'm getting [46:23] towards the end of the talk and then we [46:24] can have free form ranting um um so [46:28] question always comes when might emac [46:31] die and and and it will inevitably die [46:34] at some [46:36] point nothing lives forever um you know [46:40] keyboard maybe when keyboard sees to be [46:43] the fastest way to enter text maybe when [46:45] we have direct interfaces to the machine [46:48] uh although at that point you know you [46:50] still [46:52] want Jay please yes yeah even even then [46:56] though you'll want multiple buffers [46:58] you'll want programmability so maybe [47:01] that's just a new input mode uh even [47:04] after we directly interface our brains [47:05] to the things I I don't really know when [47:08] it will die it will die at some point um [47:11] but if we but if we're reasonably [47:13] careful about tending it and making sure [47:15] that it it remains modern and can do [47:17] modern things thus my point about things [47:20] like web kit it will continue to get [47:22] users and it will continue to have lots [47:24] of active users into the indefinite [47:25] future and anyway time for questions I [47:28] think this is my last SL [47:36] yes and I probably should be repeating [47:38] the questions so that they'll be audible [47:40] but yes I just wanted to throw in a [47:42] keyboard suggestion I've LED used for [47:45] over 10 years theis Advantage where you [47:48] have the control keys on your thumbs [47:50] that's wonderful for because now you [47:53] don't get the tunnel you don't to keep I [47:55] actually I have never never the only [47:57] times that I so the the the point was [48:00] about using about about keyboards [48:03] specifically for emac users perhaps with [48:05] control keys placed under the thumbs um [48:08] for myself I've never really had a [48:10] problem except when I have had keyboards [48:13] higher than than my wrist level if I [48:16] always keep the keyboard below wrist [48:18] level I'm okay and and and the two times [48:22] I've had trouble were when I tried using [48:24] a wrist rest which was a of the [48:27] stupidest inventions ever because they [48:29] don't make your life better they make [48:31] your life worse and and when I had spend [48:34] three months during a trading floor roll [48:36] out in Midtown typing in under really [48:40] really suboptimal conditions with my [48:42] wrists El you know bent like that um [48:46] which you know caused me to to briefly [48:49] get tendonitis issues I don't really [48:51] have the problem so long as I don't have [48:53] a lot of reach that I've got to do and [48:56] and have [48:57] uh and having control keys and what have [48:59] you on both sides is generally [49:01] sufficient for that uh I also remember [49:03] to take my watch off while I'm typing I [49:05] find I get I get [49:07] get sure this is can very easily get [49:10] well we can have all sorts of [49:12] discussions but anyway Jay uh I think [49:14] that had a question I have two quick [49:16] comments one is that um uh there is [49:18] there is actually an ID Remax that does [49:20] make it more ceded there I believe is it [49:24] is what it's called C I don't think it's [49:25] ceded we had this this was the top we [49:27] had on Facebook the discussion that [49:29] there there are a couple there are a [49:30] couple of Ides but none of the none of [49:32] the ones that are out there really parse [49:34] things like C++ as well as uh as as as [49:40] as llvm parts of C++ as it turns out a [49:43] compiler has to be able to parse it [49:45] perfectly by coincidence yes uh ji so [49:50] having been forced occasionally to use [49:52] an ID and then forgotten everything [49:54] about both the clipse andj [49:57] my main problem is not so much oh it's [50:00] not emac I don't care if it's a [50:01] particular binary what I care about is [50:04] the user interface I want to be able to [50:06] type control s or meta s and get my [50:09] incremental uh regular expression I have [50:13] well I know why I've asked once the one [50:16] of the lead Chrome developers why don't [50:18] you people put regular expression search [50:20] in the bloody search thing oh nobody [50:22] else has complained nobody ever [50:24] suggested this well I'm [50:26] first instance of a complaint about this [50:28] that I see that I saw was a talk by Rob [50:31] Pike something like 16 years ago where [50:34] he complained that the browsers didn't [50:36] have regular expression search he's not [50:38] the first one and and but but Rob is [50:40] nobody clearly nobody nobody has [50:43] complained clearly clearly Rob does not [50:46] work for the same company that makes [50:48] Crow yes yes yes but but but anyway I'd [50:51] like all of these I I would love it if [50:53] if the tool makers did better with all [50:56] of this but for now since I want to be [50:58] able to browse the web inside emac [51:00] anyway I'll I'll I'll worry more about [51:03] that but yes Jay okay this this weekend [51:05] for the first time I looked at something [51:07] called [51:09] JavaScript you're you're one of the last [51:11] people to the [51:14] I'll because of Nadim K's [51:18] Minick which I'm a strong supporter of [51:22] and um in the first place I've heard [51:25] such comments as well it's just a badly [51:27] constructed ordinary computer [51:29] programming language first place I don't [51:31] like the term programming language [51:32] they're programming systems and as a [51:34] matter fact as far as I could tell all [51:35] the criticisms are right however what's [51:39] JavaScript is not critically um is is a [51:45] programming [51:46] language it actually is are we is this [51:49] emac related it is okay it's something [51:53] it's it took me first thing I saw was [51:55] that it's imp possible to read and write [51:57] a file by default but now in JavaScript [52:01] because it's in the browser and that [52:03] would be a security violation blah blah [52:05] and then so there these things these [52:06] improvements these these environments [52:08] there's [52:09] Rhino and there's node.js and guess [52:14] what it's uninteresting as a language uh [52:17] I should have been allowed to do it with [52:19] Lis um syntax which is what he wanted to [52:23] do and um what makes it completely [52:27] different [52:28] is the execution of a JavaScript program [52:32] the default is it listens on arbitrary [52:35] many it's called them ports and then it [52:38] does something and everything by default [52:40] is quote [52:42] asynchronous and that's a big difference [52:45] from say c yeah you can write servers [52:48] and C it's a big difference from even [52:51] common list it's a big difference from [52:54] basic etc etc etc and [52:58] Eis run time is a catastrophe as you [53:02] devoted so you know that's it I mean I [53:05] mean you've got to take asynchronous [53:08] things seriously it's just a repetition [53:11] of what you said it's your complaint [53:12] about threading but it really struck me [53:14] because I'm studying it and I'm thinking [53:16] you know nobody told me how different [53:20] this system was from C basic and list [53:23] all look the same and then JavaScript [53:25] stands over here yeah okay just one next [53:29] comment yes so when I was in the top 20 [53:31] Development Group at De [53:39] uthy Junior member you're [53:43] over was 20 um I tried to do it [53:46] asynchronous command interace inside of [53:48] the command [53:50] jasus and the problem I miss command [53:52] chases to this day it's there that well [53:55] there was a reimplement [53:57] the um yes there is a reimplementation [53:59] it was for mm I think actually um but [54:02] the thing is that it was even though we [54:04] had window capability that we didn't [54:06] never release but um it was very hard to [54:10] manage the return of a asynchronous [54:13] calls I wanted to have every command be [54:16] its own right not not this background [54:20] thing un but sort of this it takes an [54:22] environment and I could you know use DCL [54:27] to push them together like they do with [54:30] a TV with a St waiting but there was no [54:33] way to really make it usable for users [54:36] the problem we had is that the people in [54:38] the room could use it and we the [54:39] technical wrers are like [54:42] no we can't describe it let alone use it [54:45] let alone tell customers how to use it [54:47] so I mean that's that's one of the [54:48] problems is is the the the coming back [54:52] you mean for using a for having a it's [54:55] at the well that's well that's one of [54:57] the reasons for for having multiple [54:59] threads around because people understand [55:00] how to progam no but after that is the [55:03] how what to do when all the [55:04] thread well you know [55:11] that I I just want to compliment you you [55:13] really when you ask about Chrome not [55:15] having regular expression searching I [55:17] mean I've frustrated at anything that [55:18] doesn't have regular expression [55:19] searching but you really haveit the nail [55:21] on the head emac is for people who live [55:23] in an editor and write text that's work [55:26] expression searching actually makes the [55:28] most sense you're not just searching [55:30] you're searching for particular pattern [55:31] that make changes to it so browsers [55:33] weren't really created as composition [55:35] engines they've been extended to do that [55:37] just like has been extended were [55:39] supposed to be but it's a composition [55:41] engine that really makes sense with [55:43] regular expression searching [55:44] fundamentally I think yeah by the way I [55:46] I know some writers who use emac you [55:49] know and are not and are not programmers [55:51] not not an enormous number like the guy [55:53] wrote the [55:54] license uh [55:57] I that's how he got [55:59] involved he is aam or at least did a [56:02] professional but but there are there are [56:04] there are but but you know the the point [56:06] is yes if you are you know emac is for [56:10] people who are generating and modifying [56:12] content especially you know through as [56:15] text is I mean I'm not even aware of any [56:18] other application people that text [56:22] than right yeah by the way I I tell my [56:25] students when when I've I've I've taught [56:27] you know intro to Unix and and Linux [56:30] students and I and you know intro [56:32] programming students I've T told them I [56:34] don't care if you pick emac or VI but [56:37] you have to pick one of them and the [56:39] reason and the reason that you have to [56:41] pick one of them is because you need to [56:43] have an text eding an environment that [56:45] you will be comfortable in for a very [56:47] long time to come and and some people [56:50] and some people get it and some people [56:51] don't I as I said I've I've had students [56:54] you know SE I've had seniors at pen [56:56] taking the operating systems Class come [56:58] to me and and and they were editing [57:00] their their you know their their project [57:03] which was a shell for Unix in notepad++ [57:06] on Windows wow and I I I have attempted [57:11] to to use the clue stick on them but it [57:13] has not actually worked the Clue by4 the [57:17] the the lart ETC but but it for some [57:20] people it doesn't take but I think those [57:22] people don't end up really as topnotch [57:24] professional programmers in the end um [57:27] next question ji so when when you [57:30] mention JavaScript I thought you were [57:32] going to mention something else which is [57:33] how JavaScript is intimately connected [57:36] to the Dawn and this is actually [57:38] something that that IM I restrained [57:40] myself yeah and and it's related to to [57:43] the to the talk because one of the [57:45] things that actually struck me so hard [57:48] and it's also related to the statement [57:49] about structure editors I don't know [57:51] anything about the da before this [57:53] weekend I guess I heard the thing I [57:54] looked at it of [57:56] course and here's here's something I [57:59] just thought [58:01] of every [58:03] UI naturally extends to become an OS if [58:07] it's used by a lot of people and we've [58:09] seen that with the browser we've seen [58:11] that with emac and so one should just [58:13] admit that's the case and one should [58:16] make sure I'm just going to repeat again [58:18] and again it's got to be asynchronous [58:21] what the hell is the difference between [58:22] the Dom and the Unix directory of files [58:25] nothing [58:27] of abstraction except more inconvenient [58:29] you the is like the presentation [58:33] system yes I mentioned I mentioned I [58:36] mentioned more the is the yes but none [58:40] of them were [58:42] designed well no no no no no you there [58:45] is there is a problem with that sentence [58:46] none of them were [58:49] designed I mean that very seriously the [58:52] whole system accreted from a series of [58:56] last minute Necessities right even [58:58] JavaScript itself even but but but we [59:00] are drifting away from em no no but this [59:02] is critical this the Synergy I think as [59:05] you touched on and I think that's kind [59:06] of related to some of these other little [59:07] discussions is that the Synergy between [59:09] a text editor that's designed for [59:11] writing code fundamentally of any kind [59:14] and a language that is built in in which [59:16] you use that coding ability to extend [59:18] the language I mean the editor uh they [59:20] work together if you're going to be [59:21] writing code you need a text editor [59:23] currently you know and if you're going [59:25] to be using a text editor it's really [59:26] handy to be writing code so I I would [59:28] argue it's not so much whether it's list [59:30] or even something like JavaScript or [59:31] whatever if it's a powerful enough [59:33] language that you can handle with doing [59:34] text I think that at that point if it's [59:37] powerful editor and a powerful enough [59:39] language integrator with it it is an emx [59:41] even if it's not the emx just as we had [59:43] when I started wasun well there there [59:45] are people who have built emac like [59:47] systems on top of hll at this point and [59:50] there have been and there have been I I [59:52] remember lugaru had something had a [59:55] commercial [59:59] em was one of the early PC yeah they had [60:02] they had HP LX they had they they had a [60:07] they had a an extension language that [60:09] was very very different from l c it was [60:12] it [60:14] was yeah but but but at this point I [60:17] think people are used to to lisik [60:19] languages so I think that that's a [60:21] logical thing to do although one could [60:23] imagine you know younger people who are [60:26] who are very very addicted to [60:28] JavaScript I was I I restrained myself [60:31] from hurling uh WX is disgusting wanting [60:34] well it has it does have certain [60:38] interesting features Javas JavaScript is [60:39] a prototype inheritance language like [60:42] self which is kind of interesting just [60:44] from a computer [60:45] science but but anyway um more questions [60:50] comment um so I just wanted to respond [60:51] to something that you and you've said is [60:54] that I actually one of the things I like [60:55] about because I don't feel like I'm [60:57] editing text I'm able to build [60:59] abstractions over the text so in list [61:01] I'm actually navigating s Expressions [61:03] I'm not editing text um which is [61:05] actually a very fundamental thing about [61:06] programmable editor because you can [61:08] actually build these these levels of [61:09] extraction and that that's what gives [61:11] you real power I the ability for me to [61:13] control meta F and jump to the end of X [61:15] expression is really powerful you know [61:18] and in some other language it could be [61:19] jump to the end of the function or [61:20] whatever it doesn't you know but the [61:22] thing is I'm building layers of [61:23] abstraction over the text right well [61:25] that's the Synergy allows you [61:28] well I remember when Unix was first [61:30] coming out people like you would try to [61:32] tell me how great it was because you [61:33] could connect these things up I'm like [61:34] just write an application but it's that [61:36] ability to put little things together in [61:38] in new ways that are so fundamentally [61:40] important about yeah to this to this day [61:43] the command line I I I I find myself [61:45] doing things at the command line that [61:46] other people seem to to not be able to [61:50] do after hours and hours and hours by [61:52] throwing together a short pipeline yes [61:55] um so can we make emac more accessible [62:00] to who um the marginal users who might [62:04] try it and go away I'm I'm not as [62:09] concerned about them and and I'll tell [62:11] you why uh I've watched for example what [62:14] has happened in the Linux Community [62:16] where the attempt to make gnome or gnome [62:20] or however it's pronounced into a more [62:23] accessible system also done by people [62:25] who didn't really understand [62:26] accessibility very well um has rendered [62:29] it not useful for the naive user or the [62:31] sophisticated user um emac is very much [62:35] a system for sophisticated users it's a [62:38] system for people who are probably going [62:41] to spend their lives editing text For [62:43] Whom the investment of a couple of weeks [62:46] to really really learn the tool is going [62:49] to pay off over the course of decades [62:52] and I would be very hesitant to try to [62:57] do anything that might [62:58] jeopardize that part of the [63:01] community uh in order to make things [63:03] more useful for people who might not get [63:06] why they want it in the first place emac [63:08] is at no risk of dying I mean as as [63:10] things I think I think to his point that [63:12] education is a really important thing [63:14] and I've seen people down emx it's make [63:17] the users well certainly the tutorial [63:19] system should probably be updated well [63:22] when I complained about it like how many [63:24] years ago to Richard course his answer [63:27] was the obvious one salzberger come on [63:29] just fix [63:30] it yes yes like this meet up would be a [63:33] wonderful place to actually teach [63:36] actually that would be well worthwhile [63:38] toite [63:39] tutorial rewrite I will say this I [63:42] learned emac I learned emac off the [63:45] tutorial and the tutorial was not very [63:47] different than it is today it's missing [63:49] a few parts I think it's pretty good in [63:51] Parts but it's missing a few critical [63:53] things it is certainly missing a few [63:55] very very useful [63:56] people aren't in the minds of rable [63:58] editor you know they're just not used to [63:59] that well that that is why I've I've [64:02] when I've I've when I've taught my in [64:04] Unix and Linux class i' I've spent a [64:06] couple of of weeks on emac because you [64:09] have to show the first thing to do I [64:11] found always is to show someone [64:13] something like like vastly refactoring a [64:16] piece of Code by with with a couple of [64:19] small macros and then saying to them can [64:20] you do this in notepad and and they [64:23] inevitably say to themselves H maybe [64:26] there is a reason I should care about [64:28] this um but but you know and and it it [64:33] it certainly it certainly is the case [64:35] that not everyone gets it but a lot of [64:37] people get it the real problem to me [64:39] though at this point is that I am having [64:41] trouble using it for all the things that [64:43] I would like to use it for the fact that [64:45] I as a fanatic can't really use it for [64:47] my email at the moment needs to go this [64:50] bothers me it needs to get with the [64:51] times it needs it needs to have you know [64:55] it needs tool I don't think that's gonna [64:57] happen though all these people keep [64:59] insisting on text emails rather than [65:01] HTML emails I'm actually the opposite [65:04] one I'm the one who like you send me a [65:05] text email and I'm going to reply with [65:06] an HTML email because I like fonts and I [65:09] like colors and I like well no but [65:10] that's fine my my problem my problem is [65:13] that all of the people using HTML emails [65:15] top post only including all of the [65:18] previous stuff they don't read the email [65:21] carefully and they don't answer 2third [65:23] of your questions because they're not [65:25] used to a process for writing that [65:26] involves it if you edited the HTML email [65:29] inside an emac mode and uh and and and [65:32] and actually bur your answers nicely and [65:35] maybe included a nice diagram or two [65:37] that would be a fine thing but people [65:39] are not doing that with their HTML [65:41] emails so can I make one last comment [65:43] really funny I worked on the symbolics [65:45] for three years I was undergraduate it [65:47] was the most amazing environment I've [65:49] ever worked in um and it was um way [65:51] ahead of time um and uh one of the [65:54] things I loved about it is that they [65:55] actually had all these Shifty Keys which [65:57] gave you access to a whole of things [65:59] including kind of you know the Super Key [66:01] the hyper key the only complaint I had [66:04] about that is that somebody at some [66:06] point in time actually gave a key bying [66:08] to control meta shift hyperx [66:11] yes this is what your nose is [66:15] for this is why you have a nose there [66:18] was a guy working on Linear B and other [66:21] people [66:22] like I just remember like going through [66:24] these questions from people who have not [66:27] asked questions so far yes something [66:30] that troubles me when you said that the [66:33] the run time for emac is okay and then [66:36] you say oh but accept the threading you [66:39] didn't even mention garage [66:41] collection I'm okay with the garbage [66:43] collection well that's one of the things [66:45] that that's one of the places you can [66:47] hang right you can't hang forever in it [66:50] you can yes you're correct the garbage [66:52] collector in order to make in order to [66:54] do the sort of thing that I'm talking [66:55] about probably has to get made a little [66:58] bit thread away though you can you can [67:01] you can pull however garbage collectors [67:03] that will do that off the shelf at this [67:04] point they're even GPL so and and I'm [67:07] just really surprised that you say you [67:09] teach operating [67:10] systems no I've I've I've I've I've [67:13] helped teach operating systems I've not [67:15] I just can't see the runtime you know [67:17] the runtime system EAC still feels to me [67:20] for a for a runtime system feels to me [67:23] like you're Dom or you're yeah it's not [67:26] uh you know it's it's it's good enough [67:28] for the moment and if one wants to do it [67:31] you know you could rewrite it completely [67:34] um however I think if you rewrote it [67:36] completely you would have trouble [67:37] keeping the existing users uh you need [67:39] to support the existing code which means [67:41] you need to support the existing e-list [67:44] which means that incremental changes are [67:46] a smarter way to make to to get from [67:49] point A to point B then then rewrites [67:52] and and I there are all sorts of things [67:54] I would like you know I mean if one had [67:56] was many years down the line off of this [67:58] you know llvm and things like it are [68:00] getting very good you know you can build [68:02] jits really easy in llvm you could slurp [68:06] the llvm stuff in and you could jit your [68:08] Elis or or your your successor to Elis [68:11] certainly a pony with that why not you [68:14] know uh IM people you know meta X Pony [68:18] you know why not um anyway uh any any [68:22] more questions at the moment or should [68:24] we uh or or or should we wind start [68:27] winding [68:30] down okay well thank you very much for [68:32] having me [68:37] [Music]