Note: I’m calling this a Red Meat Friday post because of the pushback I got the last time I broached the subject. It’s not really all that controversial.
Over at the Emacs subreddit TheTwelveYearOld asks what makes Emacs and Lisp so special when they’re used together. The answers are interesting but what struck me the most was the role that Elisp plays in Emacs. It’s not something that was tacked on later on: it’s what Emacs itself is built from.
Five years ago I was feeling grumpy and complained about the term “plugin” being used to describe Emacs extensions. I got a bit of pushback. Just because we Emacsers prefer “Package” or “Extension” doesn’t mean that “plugin” is a bad choice, they said. But it is. The word plugin, as commonly understood, refers to code that uses a predefined API provided by the host program that allows users to add limited functionality. Elisp is not at all like that. It’s not just the same language that Emacs itself is written in; the code you write lives in the same environment as the builtin Emacs code. It’s indistinguishable from the code the editor ships with. In fact, packages can be and sometimes are moved into Emacs core virtually unchanged.
Contrast this with other editors that allow you to write plugins in Lua, Javascript, or whatever. The code you write for them are plugins because they can do only what the API allows. You can’t change basic functionality or improve the algorithms the base editor provides.
At the end of the day, Emacs is—as I always say—a Lisp machine. Virtually everything in the system, except a bit of C code, is accessible to the user at run time. There’s no need to edit and recompile. You just change the running image on the fly. It doesn’t have plugins because it doesn’t need them.