I don’t usually try to explain tools that I use to other people, unless they made an explicit request as to how they could improve their workflow. However, since today is “I love Free Software” Day I think I should seize this opportunity and explain what draws me to GNU Emacs and how I use it.
Sometimes people who use computers ask me why I would use something as “bloated” as Emacs for text editing. Usually they remark that Emacs is a hold-over from a by-gone era, much too large compared to editors like “vi”, and that they are quite content using a variant of vi or some Notepad-like editor. They may have heard that you can play Tetris inside of Emacs and you can tell that they have difficulties hiding the fact that they are mildly disgusted by this abomination, a tool that seems to ignorantly contradict the Unix philosophy of doing just one thing and doing it well.
I cannot help but notice that there’s a misunderstanding; at the very least there’s an invalid assumption, namely that we agree on terminology. I do not consider Emacs a mere “editor”. To some this is folk wisdom, a now blunt blade used by the old warriors in the editor wars of ancient history:
Emacs is a great operating system, lacking only a decent editor.
I contest the second part (as Emacs has a multitude of decent editor modes, even for fans of vi), but I do agree with the hyperbolic first part: yes, an operating system indeed!
Maybe not quite in the sense of the GNU operating system, but certainly in the sense that it is a platform to run applications. In fact, it is a platform very much like a modern web browser resembles an application platform more than it does a mere HTML document viewer.
A text buffer in Emacs could hold the trail of a shell session
shell-mode), an email (
message-mode), a TODO
org-mode), a directory listing (
a text file on disk, a chat session (
ERC), a web page
eww), the output produced by an external command, etc.
Just like a modern web browser represents an environment in which
a programming language can be used to manipulate and interact
with HTML documents, Emacs is an environment for text buffers
with a language that can be used to manipulate and interact with
If you have used your web browser (or have observed someone use their web browser) to play games, listen to music, watch videos, read and compose email, edit text (e.g. by contributing to the Wikipedia), chat with friends (or chat about foes), read documentation, installed an extension—well, then the notion of a generic tool as a platform should not be a foreign concept to you. Emacs can be understood as such a generic tool providing a text interface (one of which may be a file editor).
Emacs is my main user agent—it acts as an assistant on my behalf in all matters relating to text—, much like the browser is the main user agent for documents and applications on the web to many people. This is why I hardly remember when I last closed Emacs. I do not start Emacs to edit a file; I’m living in Emacs.
Not only am I’m writing this blog post in Emacs (obviously!), I’m
also keeping track of multiple conversations on IRC in separate
buffers; I’m reading and composing email; I manage my GNU Guix software
profiles with a dedicated Emacs mode; I deal with Git through a
convenient two-dimensional text-based
user interface rather than using the one-dimensional, terse
command line interface; when I view man pages I use woman, which greatly enhances man page navigation; of course I
use Emacs as an Info documentation browser as well; my shell
sessions are in Emacs thanks to
one of those who run Emacs in a shell session inside a terminal
emulator—; I view pretty PDF documents in Emacs buffers with
PDF tools, and
even my complete personal organisation and calendar needs are
satisfied by an application running in Emacs (see Org mode).
What is crucial to understand is that Emacs is not one and the same thing to any two Emacs users. It is malleable and accessible thanks to being written in EmacsLisp. When ogres are like onions, Emacs is probably like a giant cherry: a small solid core (written in C) and a delicious mantle of sweet EmacsLisp (analogies are not my strong suit). Since almost every conceivable feature provided by Emacs is accessible through EmacsLisp and can be tweaked, rewired, or fully replaced, Emacs becomes what you want it to be.
I probably could not use an Emacs instance that has been shaped by the habits of another hacker, and they probably also wouldn’t be happy with my configuration. It’s like a tailor-made shirt in that it fits you exactly (if you take some time to take your measurements), yet it also fits like the most comfortable sweat pants as it won’t punish you if you change your sporty habits and gain weight.
This leads me to the last point I wanted to address: the claim that Emacs is bloated and ignores the Unix philosophy of doing only one thing and doing it well. I don’t know what “bloated” really means. Emacs does come with a lot of features but this doesn’t make it bloated.
I think this claim is rooted in another misunderstanding. When
you have a terminal emulator open in which you run a shell
session (like bash), and you run a command like
would not consider the shell to be bloated to allow you to
interact seamlessly with external commands. Likewise you
probably don’t object to builtin commands that cannot easily be
expressed with external executables or that make the shell more
convenient to use.
Similarly, Emacs is the perfect glue between different text-based applications. When I run a shell inside of Emacs, what Emacs really does is spawn an external shell process and redirect input and output to talk to it transparently. Or when I read email in mu4e the mail directory and its indexing database are not part of Emacs. Or when I read PDFs they are actually rendered by a separate process. Since many of these features are provided by optional extensions there really isn’t much to the claim that Emacs is bloated.
However, it is true that Emacs does not blindly subscribe to the Unix philosophy. One of its previous logos (my favourite) was an overflowing kitchen sink, acknowledging the fact that Emacs rather errs on the side of including more features rather than fewer when it is convenient. The goal of the GNU project never was to merely provide a free clone of proprietary Unices, but to give users software freedom. In the case of Emacs the boundary between user and programmer is blurred as adapting the environment to one’s needs is already an act of programming with a very low barrier to entry. Emacs provides practical software freedom and that’s one of the main reasons why over the course of many years my perception of it has slowly shifted from a belittled tool only old-fashioned people use to the centre-piece of most of my daily computing activities.
Yay for GNU Emacs, yay for free software!
Comments? Then send me an email! Interesting comments may be published here.