
Emacs users are like Terry Pratchett’s Igors - nkurz
http://chrisdone.com/posts/emacs-users-are-like-igor
======
stiff
In common understanding of emacs, its use of lisp recieves perhaps too much
attention, while its overall wonderful architecture is underappreciated. Emacs
isnt just an editor with embedded lisp, its more a vm for bootstrapping
editors. You could do an emacs with python, but the hard part is providing an
environment where the extensions dont interfere with the user input loop, with
buffer redisplay etc., while still staying easy to write. The emacs buffer-
based async handling of external processes is a masterpiece of software
engineering, much better than things like unix pipes. Doing extension
languages for interactive programs is much harder than it seems at first, and
emacs is a prime example of doing it right.

~~~
leephillips
"The emacs buffer-based async handling of external processes is a masterpiece
of software engineering, much better than things like unix pipes."

This sounds intriguing. Do you have a pointer to something I could read that
might expand on what you're saying here? (Aside from the emacs source.)

Amusing coincidence: the only Pratchet book I've read is _The Fifth Elephant_.

~~~
stiff
I will try to explain. When I came to emacs as a user, a "buffer" seemed just
a weird way of saying "tab" without displaying actual tabs. The word choice
only started making more sense once I wrote non-trivial amounts of emacslisp.
The buffer is the fundamental emacs data structure, like the file is the
fundamental unix data structure, so it's really important to understand it
well.

The definition is really simple: a buffer is just a bunch of text from some
unknown source, but in fact it is a very powerful abstraction, for two
reasons. First, every time you do something in Emacs when simply editing
files, you are really executing emacslisp functions on the buffer that is
currently displayed. A lot of things you learn in Emacs can be used in three
ways: interactively in editing sessions, when automating editing tasks with
emacslisp, and finally when doing programming in general, even when it has
nothing to do with editing files.

Second, a buffer can represent anything, it can of course contain the text of
a file, but also of only fragments of a file, or a directory file listing,
and, what's really great, Emacs binds TCP/FTP/HTTP/... network connections and
external processes to buffers as well, allowing asynchronous streaming of
incoming data into buffers, so that a emacslisp callback is called every time
new text arrives from the process or socket, you can transform it as you wish
and insert into the buffer the part to be shown to the user or kept for future
processing. Then there are lisp primitives implemented in C like save-
excursion which let you execute functions on buffer off-screen, so the same
commands that are used for editing can be used for processing HTTP requests or
grep output without the user noticing the cursor jumping back and forth or
anything of this kind. So, when I am processing HTTP requests in Emacs, I use
the same commands I sometimes use in interactive editing sessions, for example
I can use re-search-forward to check if the headers were sent completely
already and to get number of bytes they contain (the location in the buffer of
the end of the headers, in other words). A lot of the weird emacs word like
point, mark etc. that seem like anachronistic words for interface elements
really are powerful abstractions that apply as much to programming as to the
interactive editing.

Then there is a lot of other stuff that makes this yet more powerful, you can
have buffer-local variables, timers that check buffer input periodically,
transaction queues for those asynchronous processes, modes that define buffer-
specific key-bindings, menus and behaviours etc., it goes on an on. It's a lot
like node.js or other asynchronous networking stacks. There is also lot of
magic that makes all this work concurrently without Emacs having implemented
threads, and that makes it not interfere with the user interface.

A lot of the cool things Emacs does follows from this architecture, like the
SLIME package for interacting with Common Lisp interpreters (local or remote),
Dired for editing directory contents, Tramp for editing files on remote
servers, Comint for running interactive processes of various kind inside Emacs
etc. It's a really great lesson in how naturally features flow out of powerful
design ideas.

As for resources, I learnt by reading the GNU Emacs Lisp Reference [1], and
have done a lot of M-x describe-function and source code reading in the
process of writing some elisp more sophisticated than just small editing
helpers. E.g. the process stuff is described here:

[http://www.gnu.org/software/emacs/manual/html_node/elisp/Pro...](http://www.gnu.org/software/emacs/manual/html_node/elisp/Processes.html)

~~~
leephillips
Thanks for taking the trouble to write all this (when all I asked for was a
link). It gives a good flavor of what you're talking about. I used to read
network news inside of emacs, using a mode called gnus, decades ago, and
before I switched to vim. That's probably an example of a complex application
that could be written within emacs because of the architecture that you
describe. This extensibility is tempting me to try emacs again, because vim is
so hard to extend, but I don't want to give up vim's pure editing efficiency.
I guess I need to see how well evil (vim mode for emacs) works in practice.

~~~
codygman
I've been using emacs for a while (after vim for 6, 7... 8 years?) and have
recently been looking at evil. I can't seem to find any really comprehensive
tutorials for Evil mode, though I haven't put a lot of work towards it.

~~~
ZaneA
The great thing about evil is you can enable it in your .emacs and it mostly
just works. But even better, because this is Emacs the vi layer is also easily
extendable. Here's an example of adding other operators (adding `mit`, `mit>`
etc):
[https://github.com/ZaneA/Dotfiles/blob/1858a02de25e25de20e96...](https://github.com/ZaneA/Dotfiles/blob/1858a02de25e25de20e9648dd44dd3c065fc09d8/emacs.el#L79)

~~~
xiaomai
I'm tempted by emacs/evil as well, but everytime I try to make the switch I
run into two problems:

1) intial emacs setup: it feels really tricky to just get basic editor sanity
configured (auto-indent, syntax highlighting, etc.)

2) I worry that by using evil mode, I lose out on a lot of the goodness of
emacs major and minor mode's. Do you remap everything to be more vi-ish for
each mode that you use? I guess that is fine but the transition just seems
daunting.

~~~
ZaneA
I second the idea of using Prelude to start with Emacs, along with the package
manager which makes the initial setup and adding modes/stuff very easy (see
[http://melpa.milkbox.net](http://melpa.milkbox.net)).

I haven't seen any lost functionality by using evil; modes that define
bindings continue to work, and the usual C-x/C-c/M-x/whatever works fine with
evil. There is the odd major mode that doesn't work with evil out of the box
(usually if it redefines j/k) but most have no problems. You can still use
most (all?) regular Emacs movement commands with evil as well.

------
FatalBaboon
Emacs is one of those things everybody knows is good, but few take the time to
learn.

Over the years I've learnt quite a few languages, and what strikes me is that
they're all so very alike. You find the same features with slight syntactic
changes. At the end of the day, what really makes a difference is not which
language you chose but what tools you are using. Do you have to memorize every
important method or are they helping you find the documentation? What happens
when something is a little broken, wait for a fix or patch the code
immediately? Give up and live with it?

With Emacs, the languages change but the tool stays the same, you just extend
it. In a way akin to how programming enhances my mind to be able to solve
tough problems, emacs enhances my capacity to hack by letting me hack the tool
itself.

Having a userbase made of people hardcore enough to learn some Lisp so they
can hack their tool is just a bonus. Please keep fearing the parens!

Emacs is still being actively developed, v24.4 is in feature freeze:
[https://github.com/mirrors/emacs/blob/master/etc/NEWS](https://github.com/mirrors/emacs/blob/master/etc/NEWS)
(that's 1200+ lines of changelog for 24.4)

How many pieces of software can you name that have been around for 36 years
and are still kicking? Do you think it has something to do with Lisp?

~~~
actsasbuffoon
> Over the years I've learnt quite a few languages, and what strikes me is
> that they're all so very alike.

I used to think this as well, then I learned some Prolog. For those who aren't
familiar with it, Prolog is a logic programming language (as opposed to
imperative and functional languages). Instead of telling Prolog how to solve a
problem, you give it a set of facts and tell it what you want to know. Prolog
takes care of the rest, without writing any conditionals, loops, etc. At least
in theory; in my (small amount of) experience most non-trivial Prolog programs
usually involve some imperative style code. Still, it's wildly different and a
lot of fun.

There's also lambda calculus, which is crazy, and wonderful, and absurdly
difficult, and one of the most joyous experiences I've ever had. It's a
language with nothing but functions applied to other functions. Even numbers
are functions in lambda calculus, which has some fascinating implications. I
wouldn't want to build anything non-trivial in LC, but I've learned a lot
about programming as a result of studying it.

Discovering how to create singly linked lists in LC using nothing but
partially applied functions was a profound and emotional experience. I
remember how hard I laughed when I noticed that LC's false function is the
same as the Church-encoded numeral for zero. These are things most other
developers don't think are funny because they have no idea what I'm talking
about. I think a few of my co-workers suspect I should be institutionalized
when I start talking about lambda calculus.

Of course, there's also Haskell. A lot of lambda calculus is applicable to
Haskell, which makes sense as Haskell descends from the ML family of
languages, which in turn come from lambda calculus. Haskell doesn't look or
feel like most other languages, and it makes some decisions that seem really
strange at first glance. Lazy evaluation, all functions are curried, no
mutable state, all functions are pure, there are no variables, no exception
handling... the language sounds almost unusable. Then you learn about monads
and you realize that it's trivial to add support for something that looks and
feels like mutable state, except it's a system of your own design. Imagine
what would happen if you could change the way variable assignment works in
your language of choice. For instance, software transactional memory was
originally implemented in Haskell as a monad. They didn't have to modify the
language to add support. I can't think of many other languages where that's
the case, and it's a thing of beauty.

That's a long and rambling way to say that lots of languages are really
similar, but there are some wonderful languages that are extremely different.
I highly recommend experimenting with them, but be aware that your friends and
co-workers are unlikely to have any idea what you're talking about. And on the
off chance that they do understand, please let me know where you work. I want
to work with you people.

~~~
al2o3cr
+1 on the lambda calculus stuff. Here's a related talk about deriving the Y
combinator in Ruby by Jim Weirich:

[http://www.youtube.com/watch?v=FITJMJjASUs](http://www.youtube.com/watch?v=FITJMJjASUs)

(skip to about 28:00 if you're impatient)

There are additional versions of this same presentation circulating with the
code in Javascript and (I believe) Clojure. Full disclosure: Jim is a co-
worker of mine.

~~~
actsasbuffoon
I've seen a JavaScript version of that talk. My respect for Jim is one of the
reasons I switched to Emacs.

------
etfb
I'm a recovering Emacser, happy enough with less powerful but more modern text
editors. It wasn't the program or the UI that finally did me in, but the
community: I had a problem with how Emacs worked, I wanted to figure out a
solution, so I asked on #emacs on Freenode and got nothing but abuse. I
realised there's something about Emacs that attracts the sort of users I don't
want to associate with: people who are smug, self-absorbed and utterly without
empathy. Did I want to be one of them? No, I did not. Did I want to have to
rely on them for help in my work and play? No, I did not. So I found a text
editor that has sufficient extensibility and I installed that, and uninstalled
all the emacsen on all my machines. And I felt a lot better afterward.

~~~
FatalBaboon
They probably tried to make a common point: do not give the solution. For a
given specific issue, the most you should give is pointers.

For the function that solves your problem saves the day but knowing how to
find any when needed solves a lifetime of problems. Pointers help to put you
on the right track so you're not discouraged.

~~~
etfb
I was asking all the right questions -- is this possible, what hooks should I
consider, what should I take into account to make sure that the stuff I add
doesn't stamp all over other stuff. I'm a programmer with thirty years
experience and twenty years with Emacs; I know this stuff.

Basically, they shut me down. The thing I was asking was contrary to the whole
philosophy of Emacs. I had, they assured me, no right to ask it. I was an
idiot for having the problem that I was seeking to solve. And nobody, they
told me, had ever had the problem ever in all of history.

Were they right? Well, no, not even slightly. They were horribly, evilly
wrong. But _even if they had been right, their response was wrong_. Their
argument was "if you have this problem that can be fixed by a change to Emacs,
change yourself". This, in the most extensible editor on the planet. It was
like being told that my car's tendency to pull sharply to the left when
passing another car was normal and expected and I should take care not to pass
other cars.

~~~
jjaredsimpson
You used Emacs for 20 years and one bad interaction on IRC which caused you
throw away all that acquired knowledge, let alone elisp you wrote?

~~~
etfb
The camel was rather overloaded with straw by that stage. I had asked the
question two or three times over a long period, and received approximately the
same response each time.

I didn't just develop my contempt for the community all in one go. I had to
WORK at it!

------
dbalan
one thing I struggle with emacs is that I can't find a place which documents
the emacs way of doing things. Emacs has multitude of features, there are just
too many to master, yet even to know that they exist.

One example would be rectangle select
[http://www.gnu.org/software/emacs/manual/html_node/emacs/Rec...](http://www.gnu.org/software/emacs/manual/html_node/emacs/Rectangles.html),
I absolutely love them - but till one of colleague introduced them to me, I
had no idea they existed.

~~~
mickeyp
I try to write long articles explaining Emacs workflow over at
[http://www.masteringemacs.org](http://www.masteringemacs.org). You may be
interested in my latest post on discover.el.

~~~
ttuominen
I must say your blog seems like a an excellent resource, thanks for what you
are doing!

~~~
mickeyp
Glad to hear it :) Have fun!

------
mathattack
Perhaps I'm nerdly enough to go to the Terry Pratchett part of the story
first.

 _This really reminds me of Terry Pratchett’s Igor clan. I discovered this
amiable race in The Fifth Elephant. 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.
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._

Pratchett litters his books with lots of unexpected gems - I view it like
Easter Eggs for books. Could he have possibly added the lisp on purpose???

------
bachback
beautiful post. the learning curve for getting into elisp land is steep. we
need something like emacs in the future, something to evolve the emacs model
as the self-evolutionary programmer's environment. the 1M LOC code is much too
bloated for the modern age. it should be more tightly integrated with
bash/linux/git, and have better exploration methods. i am not sure why nobody
is working on this, besides lighttable. perhaps that is the problem with
emacs/lisp. finding the valuable stuff out there takes time and is not build
around sharing.

~~~
progman
> the 1M LOC code is much too bloated for the modern age.

Why reinvent the wheel? Emacs works well enough, and computers are getting
faster every generation. Many editors appeared, they all had the chance to
make Emacs obsolete but they ALL failed. Every editor could challenge Emacs
but obviously it is not so easy to compete.

I use Emacs for decades now because of its extreme stability (almost same
version among many operationg systems) and extreme reliability (not a single
crash ever). I have tested new editors from time to time but Emacs is still
superior.

These are some raasons why Emacs is still alive today despite its ancient
source code. Another reason is that Emacs depends on Lisp which is much more
stable than modern standards like Python, Javascript and HTML5 which change
pretty fast and make it difficult to keep big software up to date. For
instance, imagine an Emacs like editor written in Python 2. Now the codebase
would have to be changed to Python 3, and possibly soon to Python 4.

By the way, Haskell provides excellent support for DSLs. So it should be no
problem to develop a tool which converts Haskell plugins (or Python or
whatever) to Emacs elisp.

~~~
chrisdone
> By the way, Haskell provides excellent support for DSLs. So it should be no
> problem to develop a tool which converts Haskell plugins (or Python or
> whatever) to Emacs elisp.

I've been thinking about adding Haskell as an additional language for Emacs
alongside Elisp. It would be nice to be able to use both.

------
aetherson
I'll take issue with this claim: "Work environments are a very personal thing.
They exist to serve only one person: you. Me-me-me is a winning attitude when
dealing with your environment."

I think it's considerably more important to have a (basically good) work
environment in which your colleagues can sit down and use fluently than to
have one that's absolutely optimized to your individual tastes.

~~~
JackMorgan
If you pair a majority of the time, sure, make a standardized workstation with
your team. My team uses viemu in VS, which the rest of our office detests, but
hey, we are the ones pairing 99% of the time.

When I am not pairing for the majority, I setup my machine to my tastes, and
simply install a "default" editor for the few times someone else actually
needs to type on my machine. Emacs and IDEA both have good ways to revert
everything to defaults temporarily.

I do not believe, however, that a perfectly customized setup has only small
gains. For example, consider two tools that I have never seen as defaults in
any editor or IDE: rainbow parens/brackets and paredit mode. Rainbow parens
just highlights pairs:
[http://stevelosh.com/media/images/blog/2010/09/rainbow.png](http://stevelosh.com/media/images/blog/2010/09/rainbow.png)

And here is a short minute paredit mode explanation:
[http://www.youtube.com/watch?v=D6h5dFyyUX0](http://www.youtube.com/watch?v=D6h5dFyyUX0)

When actually editing code, those two tools save me several hundred keystrokes
an hour. And those are just the first two tools I thought to use as an example
out of the entire toolbox that is emacs.

If I was to now give up just those two tools, I would be sentencing myself to
the mental equivalent of tying five pound weights to my legs for the marathon
that is the rest of my programming career. Why would I intentionally require
myself to type more keys per hour to do the same editing, rather than just
learning a faster way to edit? This is, obviously, also my argument for
learning the vim editing system (which I also use in emacs).

~~~
aetherson
I'm not advocating accepting an editor or IDE default, I'm advocating a
standardized environment for a company. If rainbow parens are super-useful,
then they can be super-useful for everybody.

And that's another thing that a standardized environment does: it gets
techniques out there for the whole team. Because honestly I don't really
believe that all that many people are truly getting their environments
perfectly optimized for themselves. I think that most people in a shop where
everyone does their own thing end up with high un-optimized environments.

Good environments for all, that everyone can use is better than perfect
environments for a few, and mediocre environments for most, plus lack of
interoperability.

~~~
JackMorgan
I could see this for a small team _in the right circumstances_ but for a whole
company? That seems difficult if you are larger than 20. Imagine the headache
trying to get a tool approved for even a 100 person office. And who would
approve it, the manager? I see the logic that says everyone should use the
best, the problem is now you take the power from the individual who best knows
his job and give it to some central person who might not understand people's
needs as well.

~~~
aetherson
Pivotal Labs, for example, does it with much larger than 100 person offices.
They've got a repository here ( [https://github.com/pivotal-
sprout/sprout](https://github.com/pivotal-sprout/sprout) ) with their recipes
for setting up their workstations. They have 72 contributors to the repo, so I
guess it's not just a centralized manager.

~~~
JackMorgan
Do they dictate things like emacs settings? I thought sprout was for stuff
like ruby version and git configs.

------
seivan
Hmm, I am probably missing something, but isn't Igor from Mary Shelley
(Frankensteins assistant)?

~~~
ColinWright
Yes, you're missing something. You need to read some Terry Pratchett. There
are several entry points to the canon, some better suited than others to
different readers. The Igors first arrive in The Fifth Elephat, or possibly
Thief Of Time.

As an entry point (but without the Igors (yet)) I recommend "Guards! Guards!",
YMMV.

~~~
rbobby
Small Gods is also a fun place to start.

