I had quite a bit fun hacking on Emacs lately, so I thought I write a little essay about it.
This is not going to be another Emacs tutorial that explains what keys you have to press to do XY. This wouldn’t make that much sense, because of the way Emacs was designed. The very most relevant argument for using Emacs is it’s extreme extensibility: It is not simply a scriptable text editor, but a construction kit for building editors.
So Emacs can use a modal approach like Vi(m) has them. It may be a slim tool that takes less than a second to load, or a full operating environment that takes a several seconds long startup time. Pressing the i key could write the letter ‘i’ into a text buffer, switch you to insertion mode or nuke the Vatican. Changing Emacs to act exactly as you want is how Emacs is supposed to be used. If there is a feature that you are missing, you will find it on the web. And if what you want is so special that no one did it before, you can hack it into Emacs yourself.
So it makes little sense to talk about the standard configuration and features that come with a fresh installation.
I’m also not going to list cool features that Emacs does nor will I give you tips on how to use it. Instead of repeating what others already wrote many many times before, I will add some links to tutorials, essays and communities at the end.
This article is about the first thing you want to know about Emacs: “Why do people care?”. I will try to explain why many are so dedicated to text editing that they keep writing about it and why they prefer a 25 years old tool over any other text editor.
Editing Text
If you do something very frequently, even the smallest shortcut will save you a lot of time in the end. And because editing text is one of the most frequent things people do with computers, it makes sense to optimize this task as much as possible. Editing text is such a common task that there are endless ways to make you more productive. And you will continue to write and edit text for many, many years, so even if it takes you a while to figure out how you can improve that one task you keep doing, it will still save you time in the long run.
Of course, even if mostly everyone who uses a computer writes a lot of text, not everyone will want to learn such a complex tool as Emacs. The time you spend can be worth it, yes, but not for everybody.
One very important requirement is that you use a single text editor as much as you can. You might hack a whole book each day into your keyboard, but if you write that letter in word, that 10 emails in Thunderbird and use the text area in your web browser to compose blogs, you will find yourself using half a dozen different editors. And because they are all written by different people for different tasks, the only things you can rely on is a very small subset of common features.
I write nearly every longer text in the same editor. As soon as I realize this is going to be more but a few sentences, I compose my Emails, Essays, Papers, Letters, Source Code, Instant Messages, Blog Posts, Wiki Pages, Bug Reports and so on in Emacs. After I’m done, I copy it to my browser, my word processor,… I’m not lying to you, there are exceptions. I produce most of my Java code in Eclipse, which really sucks at text editing but has other features that keep me from using Emacs.
Every now and then, I review the way I work. I search for tasks that require a lot of repetition and evaluate the options I have to automate this process. If there is a solution that will cost me a reasonable amount of time, I implement the solution. First into my tool, then into my daily routine.
Why Emacs?
Once you decided that you want to use a single editor all the time, for the rest of your life, you will agree that there are obvious minimum requirements this text editor should meet:
-
It should run on all the major operating systems. If you cannot guarantee that you will always have the freedom to choose what platform you are working on, and that you will never want to switch to another operating system, you surly don’t want to spend hours/days/months/years learning a tool that does not work on your next workplace. I am perfectly fine with tools that work only on a single system, as long as they are easy to replace. A text editor is not one of these tools.
-
It needs to be highly extensible. This is maybe the most important property you should consider. If you have to rely on the editors core development team, you will wait forever for the features you need. Development teams have schedules, priority lists, other projects and, most dreadful of all, their own vision of how to work with a text editor. But if anyone can extend the tool and put the extensions online, the number of your editors features raises from n to infinity.
-
Like with an operating system, a text editor is good for end users if it is easy for developers to build stuff on top of it. Things that make developers happy include rich APIs, a powerful programming language and seamless integration of the new features into the platform.
-
The editor needs to be popular. A huge community means active development, lots of existing extensions and support. If you want to use that thing 10 years from now, someone has to continue working on it.
Once you rule out all the editors that miss one of these requirements, you will find that there are not that many choices left anyway.
The next thing you have to decide is how much time you really want to to invest. If you do a lot of text processing and you are willing to study ways to improve it, you might first consider Vim. Vim is a beautiful and intelligent designed, scriptable and powerful text editor ready to use.
Consider Emacs if editing text is so important to your life that it makes sense to invest hours/days/month/years to create a tailor-made tool that is perfectly suited to exactly your way of working. A tool that does all the things that you want the way you like it. Be aware that you should bring some technical skills with you, and hacking lisp on a Sunday evening should sound like fun.
Emacs is different
As I wrote earlier, what makes Emacs interesting is its extreme focus on customization. Here is how most editors are designed: A group of (hopefully) skilled developers create the tool, which contains a lot of features. Then they create an interface that exposes parts of that functionality as an API. Most of the time, this interface is bound to some kind of scripting language that Users can then use to write plugins, which communicate with the editor through the provided functions.
Emacs is different. Instead of communicating through an API, you edit and add to the original code itself. So your own code becomes a coequal part of the system.
“Therac25” wrote a comment on reddit that explains the difference between the two styles:
"extension language"? "integrates with"? You don't even seem to get it :-)
1. Theres "Emacs the lisp machine", which is the lisp interpreter
and core drawing libraries -- this provides a language called
Emacs Lisp, and a runtime.
2. Then there's "Emacs the editor", which is implemented in Emacs
Lisp (there's no "integration" to speak of -- they aren't
separate things). This is what people usually mean when they
say "Emacs".
3. Then there's the set of packages which come with Emacs in a
default installation -- some of which are loaded
automatically (tramp being a useful example), some of which
you have to explicitly load.
4. Then there's the code you write yourself, either as simple
configurations in your .emacs, to functions that you can bind
to a key, to changes or redefinitions of existing modules, to
entirely new modules.
There is no physical, logical, or in any way material distinction
between code at levels 2, 3 and 4. You can redefine any of the
system-provided functions in your .emacs if you want to --
everything you write or create in Emacs Lisp is on equal footing
with all of the application logic of "Emacs the editor".
As an example of this, if you put this in your ~/.emacs:
(defun delete-backward-char (n &optional killflag)
(interactive)
(insert "stinky-poo"))
You've just overridden the built-in function that handles
deleting characters -- your backspace (or delete, depending on
your keyboard) key will now call you stinky-poo for trying to
delete characters.
Addendum: I should also clarify that the ~/.emacs file is in no
way special -- it's simply a convention. You can do the above by
typing it in an arbitrary buffer, selecting it and running M-x
eval-region or even by typing it out at the M-: prompt. You can
change how everything in the the system works, dynamically, to
suit your needs.
This kind of architecture has huge advantages oder the API approach:
-
your code feels like it actually belongs to the editor. No matter if you bind it to a key, use it in some other extension or if you ask the build in documentation, your new function behaves exactly like all the others.
-
It is very easy for the core developers to integrate code into the core distribution. This is how Emacs works for more than 20 Years.
-
You are not bound to the restrictions of an API. You have full access to the whole thing, so you can do with it whatever you want.
Of course you can just use Emacs in its default configuration, without any customizations. But then you don’t take advantage of it, and, honestly, I personally would prefer Vim over a new installed, unconfigured Emacs.
So that is why so many people use Emacs, after so many years: There simply are no other editors that you can extend so freely and so easy as Emacs. If customization is your highest priority, Emacs is the only one that is popular and runs everywhere.
Finally, customizing Emacs can be fun. This is not a hobby for everyone of course, but I don’t want to create the false impression that all the hype about Emacs is just about productivity. For many programmers, hacking on a beautiful and intelligently designed tool they use every day is actually quite fun. Sometimes this can be even more rewarding than the time you save using it.
Now, as promised, some pointers to more Emacs stuff:
Get Emacs
W32 Emacs GNU Emacs optimized for Windows.
Aquamacs and CarbonEmacs are Emacs distributions for OSX.
Learn Emacs
If you want to learn how to use Emacs, the slides from its class at MIT are very good. (Yes, there is a MIT class about Emacs).
You will find tons of advise, as well as lots of extensions at the Emacs Wiki.
Wikipedia’s Emacs Page has lots of information too, like the history of the Editor.
Steve Yegge has lots of good stuff to say about Emacs. Read his Effective Emacs and all the other Yegge-Emacs stuff.
Programming in Emacs Lisp, Emacs Lisp Manual, GNU Emacs Manual are all free books that do also all come with most Emacs distributions.
