TL;DR
Claims that an editor is fully extensible because it’s written and scripted in Lisp overlook platform and runtime boundaries. Real extensibility depends on API design, platform bindings, and sustained maintenance; users often resort to creative workarounds that carry compatibility and upkeep costs.
What happened
A recent essay argues that marketing an editor as “100% Lisp” is misleading when used to imply complete, frictionless extensibility. The author notes that common Lisp runtimes and GUI stacks still rely on non-Lisp components—threading, OS integration, and low-level code—so some surfaces cannot be modified purely from the language runtime. Despite those limits, communities regularly produce workarounds: Neovim can show a scrollbar by drawing with extmarks and virt_text; Emacs users add cursor animations with patches or by combining Emacs Lisp with Python and PyQt overlays; the Emacs Application Framework embeds PyQt windows to implement GUIs. The essay also highlights dangers of unbounded extensibility: overriding internal functions can break when maintainers call internal helpers directly, and patch systems (el-patch) require ongoing maintenance. Finally, the post points out that true extensibility is a product of deliberate API design and investment, not just the language a project uses.
Why it matters
- A language-first claim ("100% Lisp") can mask real limits imposed by platform APIs and runtimes.
- Workarounds show ingenuity but increase maintenance burden and compatibility risk for users and maintainers.
- Exposing everything to customization risks breaking compatibility; strong encapsulation prevents some extensions.
- Building extensible systems requires intentional API design, historical knowledge, and ongoing effort—language choice alone isn't enough.
Key facts
- The author critiques the argument that a project being "100% Common Lisp" automatically makes every part of an editor customizable.
- Common Lisp runtimes like SBCL include non-Lisp components for threading, OS interfacing, and assembly-level code that users cannot modify from Lisp.
- GUI features such as font fallback, input methods, and screen-reader integration typically require interaction with platform-specific APIs, limiting pure-Lisp customization.
- Community workarounds exist: Neovim can render a scrollbar using extmarks and virt_text; Emacs users implement cursor animations via patches or by combining Emacs Lisp with Python and PyQt overlays.
- The Emacs Application Framework (EAF) embeds external GUI windows (PyQt) to create interface components, and Wayland compositor limitations can constrain such approaches.
- Overriding functions in Emacs can fail when code calls internal helpers directly; internal naming conventions signal such private APIs.
- el-patch lets users apply source-level patches to Lisp functions and includes el-patch-validate, but patches require maintenance across updates.
- Racket’s migration from a C core to a Chez Scheme core reportedly increased the number of people willing to modify the macro expander (from two to six), suggesting Lispy codebases can attract more contributors.
What to watch next
- How editor projects balance exposing extension points with preserving stability and backward compatibility.
- Adoption and maintenance costs of community workarounds versus investing in official APIs and bindings.
Quick glossary
- FFI (Foreign Function Interface): A mechanism that lets code written in one language call functions or use services written in another language, often used to access platform APIs or native libraries.
- Webview: An embedded browser component used to render HTML/CSS content inside a native application; it exposes a limited styling and API surface compared with native UI toolkits.
- Input method: A system that enables text input for complex scripts or languages (such as CJK), typically integrated with the operating system and often platform-specific.
- Compositor: A component in a graphical display system that composes application windows and controls how they are presented on screen; Wayland and X11 use different compositor models.
- el-patch: An Emacs package that allows users to declare and apply source-level patches to Emacs Lisp code so behavior can be changed without editing upstream files directly.
Reader FAQ
Does being "100% Lisp" guarantee an editor is fully extensible?
No. The essay argues that language homogeneity doesn't eliminate platform-specific or runtime boundaries that restrict what can be customized.
Are there real examples of extending editors despite limits?
Yes. The post cites Neovim scrollbar rendering using extmarks/virt_text and Emacs cursor animations implemented via patches or external GUI toolkits as examples of community workarounds.
Is a pure-Lisp implementation impossible?
The author states there is effectively no practical "100% Lisp" program today because runtimes and platform integrations involve non-Lisp code.
Will moving core components into Lisp always improve extensibility or maintenance?
Partially addressed: the post points to Racket’s migration to Chez Scheme, which correlated with more contributors willing to modify its macro expander, but broader outcomes depend on design and effort.
Is Lem specifically criticized here?
Not confirmed in the source.
Extensibility: The “100% Lisp” Fallacy Kana Dec 31, 2025 Comments Source Table of Contents¶ 1. The argument 2. There is no “100% Lisp” 3. Workaround-ish extensibility 4. “Spacebar heating” extensibility…
Sources
- Extensibility: The "100% Lisp" Fallacy
- Why We Hate Lisp
- Why Lisp?
- What are the main reasons Lisp hasn't evolved much over …
Related posts
- Public Domain Day 2026: Key 20th-Century Works Enter the Commons
- Why Prefer Textfiles? A 2010 Discussion and Reader Comments on the Topic
- Using WebAssembly to Build Python Extension Modules Without Native Toolchains