Tech News
← Back to articles

Extensibility: The "100% Lisp" Fallacy

read original related products more articles

For example, the Lem: An Alternative To Emacs? article from Irreal claims: (emphasis preserved)

One thing I like about it is that it’s 100% Common Lisp. There’s no C core; just Lisp all the way down. That makes it easier to customize or extend any part of the editor.

This argument sounds good: Looking at the repository, Lem is 100% 90% Lisp code; since the editor code and user customization live in the Common Lisp runtime, we should be able to extend any part of the editor on the fly, right?

Or, does it really?

Does it offer composition-function-table so that you can program your font ligatures from the editor’s scripting language?

Does it provide an API to define an arbitrary encoding system and the corresponding charset, beyond what is supported by Unicode or any existing standard?

Does it allow you to “override” its newline character, so that a file is displayed all on a single line?

These examples are taken from some of the more obscure features in Emacs, and I can go on and on. I don’t think many of the editors out there could possibly support them, as they are probably the 10% non-pure part of a “100% Lisp” system.