An argument for Emacs

After building many tools during his existence, man came to create the generic machine, the meta-machine for building other, abstract machines, the computer. What made it the zenith of toolmaking is that it is like human mind: it acted on knowledge, using knowledge as a tool, as a function for processing knowledge. And this is of incredible use, as we can now share some of our mental work with a machine, via programming it. Programme and data, pieces of knowledge, memories, that we give to the computer, for it to do millions of things for us.

An incredibly useful thing, but making a programme is difficult and nearly impossible to get completely correct. In our years with computers, we’ve created many paradigms of programming them in a more abstract, high-level way so that it’s easier to transfer our knowledge to the machine as correctly as possible, and to refine and ameliorate our programmes so that they are less and less fallible and more helping. We have created a toolchain of programmes that transforms structured text—data—to other forms of data, until we obtain binary electrical signals that the computer can process, effectuating the programme in physical world, translating it to a natural phenomenon. But in many of these toolchains, we’ve left out what was essential to the computer’s utility: that the data and the programme are of the same nature albeit of different structure, so that the programme can become data for another programme, allowing to increase complexity gradually and deconstructably, for us to be able to fix and improve different layers thereof more easily, offloading some of the burden to the machine itself. It was never impossible to take the programme as data and process it thusly, but the tools did not facilitate this. Except Lisp. Lisp reproduced what made the computer the generic machine, it made the programme of same nature with the data. The concepts of homoiconicity and interactive programming are certainly not confined to Lisp, but they’re best represented within it.

Today computing has become a daily task, and programming multiple computers is done by everybody—even by the grandma killing time in Facebook on her tablet computer, she’s essentially interacting with a computer and programming it—, and different groups of computer users need different sets of tools. Of most of us who are, one way or another, in a computing environment nearly every day, some prefer to confine oneself to superficial interactions with the generic machine, through application software on opaque devices, and some prefer to be more sovereign over their toolchains. The latter ones, of which I too am a member, lean towards environments that are deeper in the layers of abstraction covering the physical phenomenon of computation, while the former ones mostly lives on the highest layer possible, limiting themselves to using what’s already there, taking it for granted. The latter group includes software (i.e. programme) developers, ‘power users’, ‘system administrators’ and ‘hackers’, while the former is practically everybody else. I’ll refer to the latter group as ‘hackers’ 1, and the former as the ‘clientele’. The two groups are not completely distinct, and do overlap. So, the hackers want more fine-grained and strict control over how their computations proceed, be it fetching, sending and reading electronic mail, writing textual documents or creating programmes on a computer, navigating the Internet, manipulating personal data, etcetera. And thus, they use computing environments that they can programme more directly and more extensively, and there are some such computation environments that are more popular than others: Unix clones and Emacs are among them.

Unix 2 is a system that allows combining programmes and flowing data through arbitrary chains of them, allowing the user to fruit the results and side-effects of such process, called a ‘pipe line’. The programmes used in this fashion are called ‘filters’, for they filter streams of data and pass them on probably after modifying it. Another kind of programmes, ‘applications’, have a different relation with data and with their users, they interact with data and user directly. They don’t receive, process and spit data blindly, but they allow the user to manipulate it directly, in the application. For example, a music player is an application, because it finds its data itself, and processes it in base of the user’s commands. Another such ‘application’ is the ‘text editor’, which allows the user to interactively edit text files stored in a computer. I’m creating this article in one such application, ‘GNU Emacs’ 3, which is running on a Unix-like system, ‘FreeBSD’. Emacs is a fairly unique application in that it provides the user with a computation environment that is nicely and consistently wired together and easy to extend and customise. So, albeit it runs already on a computing environment, the operating system, it provides a second one.

This programming environment has some very useful traits which renders it easier to be programmed directly. First, it is a Lisp environment, so it provides the user with a programming tool that allows for gradual creation of complexity and easier, more natural manipulation of data. Second, it is an interactive programming environment which the user can simultaneously use and programme, allowing him to incrementally build his tools and improve them. Third, its user interface is mostly unified with its data, i.e. text, so that it’s easier to compose any of its tools to interact with its different parts. With this system where the user interface and data, and the programme and data are of the same nature, and the programming is interactive, it becomes natural and simple to create and grow a computing environment completely adapted to the individual user’s needs and his way of working. Any knowledge about any part of the system is transferable to other parts of the system. In comparison, in Unix, the tools at hand are more opaque, experience is less transferable, and the usage is more like batch processing than the interactive, incremental way of Emacs. There are many different programming languages that different tools like ‘awk’, ‘sed’, ‘perl’ etcetera understand, and knowing one is not very helpful at learning the other. Most of the programmes are configured with text files without a common syntax, so that to configure a tool, one has to learn a new language, besides learning the dynamics of that tool. Whereas in Emacs everything is done in Emacs Lisp language, and there are many common themes, like ‘hooks’, ‘modes’, ‘advices’, and thus the user need not start from nothing when dealing with a new subsystem (i.e. a new tool), and does not need to remember many different protocols when improving their environment. In Unix, in order to configure a subsystem, i.e. a tool, most often the tool needs to be taken offline, configured, and rerun. This makes exploration rather cumbersome, requiring the user to switch context many times. But in Emacs, the user can, while on his task, fiddle with the tool’s settings or do something else, and continue, without a context switch. And because he learns the usage basics once and the knowledge is transferable, he saves himself from the burden of remembering many subtle (or not) and unnecessary little differences in programming different tools for getting a vast array of tasks done.

I read and write email, read and compose documents, navigate the internet, and create my little computation tools in Emacs, and knowing only Emacs Lisp, I can use all this tools; modify, extend, configure, and combine any of them, and interactively, incrementally and gradually make my computation environment my home, adapted completely to me, whereas in a system like Unix, every other part of the system feels like a different hotel room, where every time I switch from one to another, I have to learn anew simple and basic things and deal with unnecessary and subtle differences, and I cannot modify anything as deeply and fundamentally as I can at home. And therefore, I choose to do as much of my computational tasks as I can within Emacs, benefitting these pros of it.

I wanted to write this article to describe how and why I use Emacs, and how it is fit for me and computer users like me. Albeit, while I’m trying to put forth an argument for utility of Emacs, I’m not arguing that it’s universally useful: I acknowledge that while it’s a helpful environment for an explorative hacker, for many kinds of users it’s just unhelpful. What I actually wanted to get at is the widespread thought that Emacs is a ‘text editor’, no, editing text is just one of it’s many and unlimited functions, albeit a fundamental part of its user interface. After reading the article The Bipolar Lisp Programmer by Dr Mark Tarver, which I encountered on Hacker News, I gave a deeper thought as to why I was a happy Emacs user, and found that, it is fit for those who like to work like me, and that my way is very similar to many others—whose common traits are described in the aforementioned article—, as Emacs allows sporadical, incremental and interactive tinkering with the system, and once the user learns the basics of the system, and proceeds to extend and modify it, there are way less initial obstacles that can divert his attention or dishearten him.



The concepts ‘hacking’ and ‘hacker’ are very nicely explained by the Richard Stallman article On Hacking. I’m using this term to mean ‘tinkerer, technical explorer’, not ‘malevolent breacher of digital security’.


When I say ‘Unix’, I refer to modern ‘Unix clones’, systems like GNU, GNU/Linux, BSD descendants, and other systems. The actual, historical Unix is long dead.


Emacs is actually a family of similar applications, among which there are XEmacs and GNU Emacs, which is the most popular Emacs by far.

Copyright © 2013-2017 İ. Göktuğ Kayaalp.