All Topics
All Topics
Technology
Technology
Design
Design
Programming
Programming
Science
Science
News
News
Gaming
Gaming
Entertainment
Entertainment
Business
Business
Finance
Finance
Sports
Sports
Health
Health
Food
Food
Travel
Travel
Art
Art
Music
Music
Books
Books
Education
Education
Politics
Politics
Personal
Personal
No algorithm. No AI slop. No ads. Just RSS. Pro-human. Indie writers. Real journalism. Open web. Chronological. Hand toasted.

The Limits of Lisp Extensibility: A Critique of "100% Lisp" Claims

By

todsacerdoti

5mo ago· 2 min readenInsight

Summary

The article critiques the common argument that Lisp-based editors like Emacs offer perfect extensibility because they're written in Lisp. It argues that while Lisp provides good extensibility, it's not unlimited - developers are still constrained by coding conventions, existing code, and the fact that not everything can be extended without breaking functionality. The author provides a concrete example from Org-mode where overriding a function (org-export-get-reference) doesn't work because Org-mode sometimes bypasses it by calling org-html--reference directly.

Key quotes

· 4 pulled
Compared to extending via workarounds, extending in 'pure Lisp' can be both easier and harder, as we are still bounded by coding conventions and existing code, and one cannot possibly extend everything without breaking some of them.
It's not wrong, but I think it does overlook a few things.
Oh no! It turns out that, sometimes Org-mode directly calls org-html--reference, bypassing our override.
one of the most common arguments seems to be: 'it's written in This Lisp and also scriptable in This Lisp, and that gives it great extensibility.'
Snippet from the RSS feed
So, I've seen some articles promoting Emacs-like editors written in Lisp languages, and one of the most common arguments seems to be: "it's written in This Lisp and also scriptable in This Lisp, and that gives it great extensibility." 1 It's not wrong,

You might also wanna read