Extensibility: The "100% Lisp" Fallacy

Coders clap back: “Pure” doesn’t mean flexible, and the comments are savage

TLDR: The post argues “100% Lisp” editors aren’t fully flexible because real-world systems rely on parts you can’t change. Comments erupted: sarcasm, feature drops defending Lem, calls to modernize Common Lisp, and nostalgia for Lisp machines—turning a tech claim into a community showdown over purity vs practicality.

A spicy New Year spat broke out over the myth of “100% Lisp” editors—programs written in the Lisp language that supposedly let you change anything. The article says: cute slogan, but reality is messier. Modern editors still rely on operating system bits you can’t tweak, and even Emacs—the granddaddy of tinkerable editors—has wild edge-case features that push past “pure” claims. Cue the crowd: jibal immediately deadpanned, “It’s not wrong—Glad we settled that,” turning the thread into a meme factory.

Then vindarel rolled in with receipts, listing how Lem keeps shipping features—like new language support and visual helpers—basically shouting, “Don’t count us out!” Meanwhile acuozzo wagged a finger at history: no mention of vintage Symbolics Lisp machines, the OG “everything-is-Lisp” computers. And xvilka went full reformer, arguing the Common Lisp standard itself needs a glow-up, shouting out proposals and modern add-ons like typed extensions and pattern matching.

The vibe? Half “marketing vs reality,” half “old-school vs new-school,” with jokes about “Lisp all the way down” and screenshots of editors glued together with hacks—think scrollbars faked in Neovim and Emacs windows layered with Python tricks. It’s messy, it’s nerdy, it’s deliciously dramatic—and it proves extensibility is less purity, more ingenuity.

Key Points

  • The article challenges the idea that editors written and scripted in the same Lisp are fully extensible, using Lem and Emacs as reference points.
  • It argues that certain deep editor features (e.g., ligature composition, custom charsets/encodings, newline behavior) are typically outside the scripting layer.
  • There is effectively no “100% Lisp” system: runtimes and GUI editors rely on non-Lisp components for OS/threading and platform-specific APIs.
  • FFI lets Lisp code call external systems but cannot extend control beyond what those systems (e.g., webviews, CSS, IMEs, screen readers) expose.
  • Developers often achieve extensibility through workarounds, such as Neovim scrollbars via text rendering tricks and Emacs GUI overlays via Python/PyQt or EAF.

Hottest takes

"Glad we settled that" — jibal
"Recently added in Lem: tree-sitter for JSON, YAML, Nix, Markdown, WAT" — vindarel
"Common Lisp standard ... really needs an uplift to shine" — xvilka
Made with <3 by @siedrix and @shesho from CDMX. Powered by Forge&Hive.