Nice to see Emacs getting a bit of press recently. I’ve used it for almost 20 years now and it dominates my time at the keyboard. It isn’t perfect and I’m reluctant to recommend it but I wouldn’t want to be without it. Let me explain.

The best thing about Emacs is that it can do everything (including the things it can’t do yet). The worst thing about Emacs is finding out how it does anything. I wouldn’t call it discoverable. In fact, on several occasions, I’ve learned about Emacs by accident: you press the wrong key combination (easy to do when you’re holding down a couple of keys and stretching for a third) and, look, something interesting happens!

The rest of this article describes a few of these happy accidents: modes I never knew about and tricks I wish I’d learned earlier.

Whenever I see the Emacs splash screen (click on the graphic for a close-up) I’m amazed anyone ever gets past it. Computer users want instant gratification and a familiar interface — thus the encouraging tip:

You can do basic editing with the menu bar and scroll bar using the mouse.

Unhappily the rest of the screen discredits this friendly proposition. Where are the menu and scroll bars[1], and what’s with all the Control this and Meta that? If the scratchy artwork and bizarre mix of font styles don’t put new users off, the remaining content surely will, with its dark warnings about sessions crashing and how to recover[2].

Best of all, though, is the opening proposition:

GNU Emacs is one component of the GNU operating system

which I read as a straight-faced rebuttal of the old gag:

It is a common joke, both among fans and detractors of Emacs, to describe it as an operating system masquerading as an editor[3].

GNU hasn’t quite become an operating system but it does supply most of the standard Unix tools and Emacs works beautifully with them — even on (Cyg-)Windows. META-! executes a single shell command, for example. META-| executes a shell command on the current region and puts the output in a temporary buffer. META-X grep and META-X grep-find build search on top of grep and find . META-X shell opens up a shell window within Emacs, meaning you can run shell commands and process their output using the standard editor commands. Emacs info is a better man page browser than info. And so on.

OS integration examples META-! META-| META-X grep META-X grep-find META-X shell

When Emacs shells out to external tools their execution is never hidden from you, so you lose none of the power of these tools. The converse of this also holds: if you don’t know how to use grep and find , even basic search commands in Emacs will seem cryptic and hard to customise. Emacs is, above all else, customisable. In fact, most of Emacs is customisation, and you’ll soon give up on it if you can’t accept this[4].

Over at Coding Horror, Jeff Atwood talks about “large display paradox”:

One of the advantages of small monitors, ironically, is that because they’re small, they nudge users into a simpler, windowless method of working. Instead of wasting time sizing, moving, and z-ordering windows, users only need to deal with one maximized window at a time. They can flip between maximized applications in much the same way they change channels on the television. But once your display gets to 1600 x 1200 or beyond, this easy one-app-per-display model isn’t feasible any more … That’s the large display paradox. Having all that space can make you less productive due to all the window manipulation excise you have to deal with to make effective use of it.

Well, I reckon Emacs has this problem cracked. On a small screen you can use a single maximised window: CTRL-X B switches editor buffers (a bit like tabbed browsing) and CTRL-X CTRL-B gets you a buffer management window. On a large screen CTRL-X 3 splits the enclosing window vertically, and CTRL-X 2 splits it horizontally. Repeat these commands to slice up your work space. CTRL-X 1 gets you back to a single window. The same commands work when you haven’t got a proper windowing environment — on a stripped down server for example, or one which hasn’t booted properly. Very handy!

Buffer and window management CTRL-X B CTRl-X CTRL-B CTRL-X 3 CTRL-X 2 CTRL-X 1

If, for example, the stripped down server discussed in the previous section allows SSH access or similar, you don’t need to install or run Emacs natively. Just use tramp mode (Transparent Remote file Access, Multiple Protocol). Quoting from the manual:

To access the file localname on the remote machine machine you would specify the filename /machine:localname. …

You can specify protocol (ftp, rsh, smb etc.) and user name too:

So, to connect to the machine melancholia as daniel , using the ssh method to transfer files, and edit .emacs in my home directory I would specify the filename /ssh:daniel@melancholia:.emacs .

You can omit both username and protocol: the former defaults to your current username, the latter to SSH. As usual, there are plenty of configuration options. I haven’t touched any of them. Tramp mode just works: if I can access a remote machine, I can edit files on it and transfer files to and from it just as if it were local.

Remote editing example Find file: /ssh:daniel@melancholia:.emacs

Programmers often need to view the raw bytes packed into a file, and occasionally to edit these byte values. That’s what Hexl mode is for. META-X hexl-find-file opens a file in this mode and META-X hexl-mode switches a buffer to this mode.

META-X hexl-find-file META-X hexl-mode

Did you know that Emacs can work on .zip , .tar , .tgz etc archives directly? I found out when I opened one by accident: Emacs presents you with a view of the archive and you can browse files, edit them, rename them, remove them from the archive, and save the modified archive without ever having to manually extract it. No special knowledge required: it just works, a bit like dired-mode .

If you open a directory with Emacs it puts you in dired-mode, the Emacs take on Windows Explorer, OS X Finder and so on. Many of the Emacs users I know don’t use this mode, preferring either the native system file manager or plain old terminal windows for file operations (copy, move, list, …) but I use it all the time and it’s led to many happy Emacs accidents.

As an example, suppose you have a directory full of files with names-like-this , and you want to rename all the files to use names_like_this instead. Just switch to editable dired mode, run a standard search and replace to swap hyphens for underscores, then save the directory.

As a second example, suppose you want to view thumbnails of all the .png files in a directory. Use a pattern match % m png to “mark” them (i.e. select them) then CTRL-t d to display them. Now you can visit the thumbnails, removing, renaming, copying the associated files.

Cryptic, yes, but powerful, and no mouse required — handy for laptops.

You can hear when someone sitting nearby doesn’t know about editor macros or is using an editor which doesn’t support them. The tedious repetition of the same sequence of keystrokes grows audible.

In Emacs you start recording a keyboard macro with CTRL-X ( and finish recording with CTRL-X ) . Everything typed between these bracketed commands has been recorded as a keyboard macro which CTRL-X e executes and then e repeats. If typing all those eeeeee ’s is repetitive, supply a repeat count. A repeat count of 0 processes the whole buffer, and is often what’s wanted.

There’s far more to keyboard macros but this basic use alone will save your fingers and your sanity.

CTRL-X ( CTRL-X ) CTRL-X e

Emacs has a proven architecture: a compact, stable core which is dynamically configured by a huge library of scripts. These scripts are written in elisp. You can edit, reload and add to them at any point, without the need to reboot the main application. Rebooting wouldn’t be such a big thing, though — Emacs starts up in less than a couple of seconds — what’s important is that Emacs is dynamic to the core.

So it’s not surprising Emacs has great modes for dynamic languages like Python, Ruby, Scheme. Here’s how to develop Python code using Emacs:

Pull up a full-screen window

Split the window vertically

Use one side for the code you’re working on

Use the other side to run an interpreted session

Switch sides as desired

You continually select regions of code to execute. You step into the interpreter and use the Python help command to get help on modules and functions — including the ones you’re creating right now. You rework a function in one window then exercise it in the other. You sketch experimental code, run it, rub it out.

The same technique works for Scheme and Ruby, and is likely to work for any other dynamic language. The gap between writing and running code disappears.

As computers grow more powerful, specialised programmers’ IDEs do what they can to support this style of working for compiled languages. I understand Eclipse parses, compiles, and executes Java code as you write it, and it’s certainly an impressive piece of software. I’d be interested to know how it fares with C++.

Emacs also works well enough with compiled languages. I’ve heard Make described as REPL for compiled languages, and make -k is the default Emacs compile command. The usual IDE things are available. For more interactive probing of a compiled executable, META-X gdb is about as good an interface to GDB as I’ve seen. But I can’t (for example) imagine Emacs persuading anyone to dispense with Visual Studio for .Net development.

This article cherry-picks a few Emacs modes you may not have discovered which I find invaluable. I haven’t bothered listing the basics of how to open or close files, without which you won’t get anywhere. One basic command I do want to mention is META-/ , which dynamically expands whatever you’re typing whatever mode you’re in. I think of it as code completion for cheats, since it doesn’t parse any source code and it works equally well on any type of file type. It’s as useful as shell TAB-completion and I discovered it by accident.

You can’t edit photo, video or audio content in Emacs (perhaps I should say I don’t know of an Emacs mode for doing so[5]). I don’t use Emacs for spreadsheets or other “office” documents. You can use Emacs for ascii-art (and here’s a great flash animation showing someone do just that) but ascii-art doesn’t look much good outside source code.

Hardcore Emacs users swear by their editor as an email client and even use it as a web browser. I prefer the comfort of my second most used application, Firefox. Come to think of it, Firefox adopts a lot of what’s good about Emacs: the tabbed window, for example, which reinvents multiple buffers for the web browser; the clean, simple look[6]; the extensible architecture.

Funnily enough, you can work with photo, video and audio using Firefox; and boring old online office suites have been news for a long while. Amazingly, you can continue to edit your rich media content even if you switch to Internet Explorer, without the need to relearn anything; a transition which puts the Vi/Emacs wars into perspective. Could the web browser be the one true editor of the future?

My thanks to Hugh Brown for pointing out a couple of errors with the original version of this article.

[1] OK, so my .emacs disables the scroll bar and menu bar before this splash screen appears, but telling people what their mouse is for hardly seems necessary.

[2] I can’t remember when Emacs last crashed on me. It’s one of the three applications I auto-start on login and I usually leave it running until I shutdown. On occasion I’ve forced it to quit but this has always been down to my own error, for example coding and executing (within Emacs) a tight loop.

[3] Quoted from Eric S. Raymond’s excellent book “The Art of Unix Programming”

[4] In “The Art of Unix Programming” Eric S. Raymond discusses the question: “Is Emacs an Argument against the Unix Tradition?”. This is a rather long quotation to include here, I know, but I’m sure the author wouldn’t want me to alter his words in any way. I highly recommend the book and suggest you buy a copy to read in full.

The central tension in the Unix tradition has always been between doing more with less and doing more with more. It recurs in a lot of different contexts, often as a struggle between designs that have the quality of clean minimalism and others that choose expressive range and power even at the cost of high complexity. For both sides, the arguments for or against Emacs have exemplified this tension since it was first ported to Unix in the early 1980s. Programs that are both as useful and as large as Emacs make Unix programmers uncomfortable precisely because they force us to face the tension. They suggest that old-school Unix minimalism is valuable as a discipline, but that we may have fallen into the error of dogmatism. There are two ways Unix programmers can address this problem. One is to deny that large is actually large. The other is to develop a way of thinking about complexity that is not a dogma. Our thought experiment with replacing Lisp and the extension libraries gives us a new perspective on the oft-heard charge that Emacs is bloated because its extension library is so large. Perhaps this is as unfair as charging that /bin/sh is bloated because the collection of all shellscripts on a system is large. Emacs could be considered a virtual machine or framework around a collection of small, sharp tools (the modes) that happen to be written in Lisp On this view, the main difference between the shell and Emacs is that Unix distributors don’t ship all the world’s shellscripts along with the shell. Objecting to Emacs because having a general-purpose language in it feels like bloat is approximately as silly as refusing to use shellscripts because shell has conditionals and for loops. Just as one doesn’t have to learn shell to use shellscripts, one doesn’t have to learn Lisp to use Emacs. If Emacs has a design problem, it’s not so much the Lisp interpreter (the framework part) as the fact that the mode library is an untidy heap of historical accretions — but that’s a source of complexity users can ignore, because they won’t be affected by what they don’t use. This mode of argument is very comforting. It can be applied to other tool-integration frameworks, such as the (uncomfortably large) GNOME and KDE desktop projects. There is some force to it. And yet, we should be suspicious of any ‘perspective’ that offers to resolve all our doubts so neatly; it might be a rationalization, not a rationale. Therefore, let’s avoid the possibility of falling into denial and accept that Emacs is both useful and large — that it is an argument against Unix minimalism. What does our analysis of the kinds of complexity in it, and the motives for it, suggest beyond that? And is there reason to believe that those lessons generalize?

[5] So now I know better! In a comment on this site, Johan Lindstrom says you can edit video using Emacs, http://1010.co.uk/gneve.html, and in an email Arnold Mátyási pointed me at this YouTube GNEVE demo, while over at reddit another comment mentions an audio editing mode, http://delysid.org/emacs/ecasound-el.html.

[6] Splash screen excluded!