Emacs Users Are Like Terry Pratchett's Igors
darkfeline writes:
Since we had an article espousing Vi(m)'s signature feature of operator composability, it seems only fair to talk about Emacs's signature feature, extensibility.This article does a good job, in my opinion, of describing the Emacs epiphany.
Within the constraints of the Emacs environment, there are no limits. Emacs is built upon this principle: [...] Make some small kernel of features. [...] Take care to make this substrate programmable, and then build the system upon it. Let users worry about future features. [...]
My road to Emacs love developed slowly. I first came to it due to Common Lisp. I knew enough Lisp to get by, copy-pasting example snippets, configuring just enough to edit my environment. [...]
Eventually I started patching some things here and there, writing my own hooks, little things like that. [...]
Finally, I wrote my first mode [...] It wasn't very good [...] But it gave me some key insights. This thing isn't just an editor, it's really an environment all the way down. I can configure everything about this mode. [...] It's all code.
After that, it was really a sky-rocket of productivity. Eventually I would write Elisp casually in between programming on work projects. I would notice that a way of working was repetitive, or that Emacs behaved in a way I just didn't quite like, or I simply thought of a nice thing that I could add. I'd happily spend anywhere from 30 seconds to half an hour writing some functionality to extend my editing facilities.
And it was extended for good. That amazed me, and still does. My problems are only problems for as long as I don't notice them. Once I do, I write some Elisp to solve it, and then it's never a problem again. In typical editors and IDEs, I simply wouldn't even think of fixing such things, never mind actually putting my work to one side for a minute, solving them, and then going back to work again. [...]
This really reminds me of Terry Pratchett's Igor clan. [...] Igors are a people inspired from the typical hunchbacked Igor archetype, but in Discworld, they are also self-modifiers. Their bodies consist of mixed and matched and patched and swapped body parts among other members of their clan, of scars and self-adjustements [sic]. They are infinitely self-improving, self-experimenting. They might end up with a botched job and have to hobble around for a few days, but in the end it's always fixable.
And they lisp.
If you're interested in a more technical treatment of Emacs, you can read the paper that Richard Stallman presented to the ACM Conference on Text Processing. One of the things that he covers is the need for separate editing and programming languages (*cough* Vim and VimScript).
Previous attempts at programmable editors have usually attempted to mix programming constructs and editing in one language. TECO is the primary example of this sort of design. It has the advantage that once the user knows how to edit with the system, he need only learn the programming constructs to begin programming as well.
However, there are considerable disadvantages, because what is good in an editor command language is ugly, hard to read, and grossly inefficient as a programming language. A good interactive editing language is composed primarily of single character commands, with a few commands that introduce longer names for less frequently used operations. As a programming language, it is unreadable if the editor is to be customizable, the user must be able to redefine each character. This in a programming language would be intolerable!
Read more of this story at SoylentNews.