Mastering Emacs

A series of rabbit holes, some of which led to unshaved yaks, recently landed me on a book called Mastering Emacs. Given that I have been using Emacs "professionally" for more than 16 years—and first looked into it a good ways into the previous century—I should probably be pretty well-versed in that editor-cum-operating-system. Sadly, for a variety of reasons, that is not really true, but the book and some concerted effort have been helping me down a path toward Emacs-ian enlightenment. Mastering Emacs may also help others who are struggling in the frothy sea that makes up Emacs documentation.

The backstory of how I got here is kind of goofy—some days rabbit holes look like so much fun ... and they definitely can be, but the lost "productivity" may be problematic. In any case, a Hacker News item on "Elixir for cynical curmudgeons" caught my eye a few weeks back since I certainly qualify. After reading that and poking at Elixir (and Erlang) documentation some, I remembered that I always wanted to understand Lisp macros better—or at all, in truth. That led me back to a project that I started (and promptly drifted away from) after a talk at linux.conf.au about the history of Lisp that I really enjoyed.

That project was, naturally, a Lisp interpreter. It is written in Python and is, at best, 5% complete—and likely not to go too much further. But I dusted it off, made it work for some more Lisp constructs, and suddenly realized that I did not know enough Lisp to even be setting off on such a journey. That should be a solvable problem, so I sought out some more Lisp wisdom and came across "A Road to Common Lisp". It seemed like it contained sensible advice, some of which I started to follow, but then ran into some annoyances using Lisp from the command line. That, inevitably, led to SLIME.

Of course, given that SLIME is also known as the "Superior Lisp Interaction Mode for Emacs", that leads to Emacs, which is an editor I use in anger on a daily basis. It is not, however, my editor of choice; I have been using vi (and its variants) since the early 1980s and it is the editor I reach for—except for work-related tasks. A day-one surprise when I started full-time at LWN in 2007 was that Emacs was closely intertwined with the site operations (article editing, in particular). That led to a crash course in just-enough-Emacs to get by, which has mostly served—for good or ill—since.

In truth, I am not a "power user" of any editor; I suspect that I could still function perfectly well in the Berkeley Unix version of vi that I learned on, lo these many years ago. I may well have only scratched the surface of its capabilities as I am not averse to brute-force solutions to editing problems. But, over the years, I have picked up a few more Emacs "tricks" and been impressed with all that it can do. It has always intrigued me that it can be transmogrified using Lisp, as well.

There are, evidently, add-ons for Vim that fill the same niche as SLIME, so I could have taken that path, but Emacs seemed like the right choice. I can be stubborn in weird ways, such as by ignoring Evil mode, which provides a vi-like experience for Emacs. What little I remembered from my first toe-dip into the Emacs waters—using the GNU Emacs manual with the yellow cover in the mid-1980s—stuck with me (mostly just Control-x Control-c, or C-x C-c, to exit), so I was determined to forge ahead on that path in my 2007 crash course and, of course, since.

The book

So, once I started messing with SLIME, I came to realize that I was lacking the knowledge of some major underpinnings of Emacs. I had encountered Mastering Emacs before, considered buying it, and got distracted before doing so. The Mastering Emacs web site is an excellent resource in its own right and one that I had visited along the way. Right around the time I started my SLIME investigation, a Hacker News post about the book showed up; when I saw that the book was on sale in the comments on the post, I took the plunge and bought it.

Other than "lost" time, I have not even remotely regretted the purchase. Mickey Petersen has done an excellent job with the book and it is well worth its full price ($49.99) in my opinion. I am still working my way all the way through it—and will undoubtedly refer back to it regularly. It comes in both PDF and EPUB formats; there is no "dead tree" version. Petersen detailed the process of writing the book (in Emacs, naturally) on his site; he hired a professional editor to help him, which was a nice touch. The articles on his site are well-written, though, so perhaps his editor did not have all that much work to do.

It is an opinionated book, and rightly so. A dry recounting of the options and possibilities within Emacs would be far less useful. Which is not to say that such a manual does not have its place—and one of those places is inside Emacs itself, of course. But Petersen is providing a sort of guided tour of Emacs, describing pieces of the editor in a way that makes sense for a narrative, rather than a reference. Along the way, he clearly indicates what his opinions are, why he has them, and how that changes his Emacs environment. There is no expectation of rigid adherence to his suggestions, however; some of them I have adopted, others not, and I have made a few customizations of my own. None of that interferes with the rest of the book in any way.

The organization may seem a bit strange at first, but it has grown on me. Beyond the introductory material, he starts with the philosophy of Emacs, which is an important underpinning. Understanding that "Emacs is a tinkerer's editor" is fundamental to working with it. He notes that much of that tinkering will require learning some Emacs Lisp (elisp), which intimidates and chases away some potential users, sadly.

The book has a nice justification for "why Lisp?" that resonated strongly with me. It makes sense that a language where there is no distinction between code and data would be the basis for an editor (and so much more) that is Emacs and its ecosystem. Obviously my interest in delving further into Lisp made it easy to buy into the justification; others may not find it so compelling.

Terms

The "Important Conventions" section provides something of an impedance-matching layer between Emacs terms and those that are used elsewhere. Terms like "window", "frame", "mark", "point", "buffer", "kill", "yank", and so on have specific meanings in Emacs; some of them are confusing because they conflict with current usage. In many cases, Emacs started using these terms before the other uses came about, but it was not popular—or visible—enough to "enforce" its prior art.

That section also describes the buffer interface, its modeline, and mini-buffer. Buffers are the basic unit of interaction in Emacs, which can be displayed in windows, that are contained in frames. These days, of course, a window has a much different meaning, which generally corresponds to an Emacs frame. Buffers can have one major and multiple minor modes as well. Wrapping one's head around all of these terms is important, but the book has not even started talking about how to install or start up Emacs at this point.

It gets there, of course, and suggests that readers run the latest Emacs available, which is (or was) Emacs 28; since then, Emacs 29.1 was released. Petersen has a lengthy article that annotates the Emacs NEWS file for the release with the features that he found interesting. That is presumably partly in preparation for an updated version of Mastering Emacs before too long. Updates to the book are free for those who have purchased it.

One might guess that next up might be editing text, but that part does not actually come until a little ways beyond the midpoint of the 300+ page book. Before you get there, there are lengthy descriptions of the key sequences used by Emacs, which is certainly an area that those who are new to the editor will need to grasp. One of the most strongly worded opinions that Petersen offers is to remap the Caps Lock key as Control; in fact, he suggests disabling the left-hand-side Control key entirely. So far, I have been unable to take that last step, as there are decades of muscle memory to overcome. Eventually, remapping that key to Meta (the other major Emacs modifier key) has some appeal, but may prove to be insanity.

The extensive customize interface (M-x customize) is described in some detail; it allows changing an unbelievably vast array of options. Those changes can be just for the session or can be saved in the startup file (normally ~/.emacs.d/init.el these days, apparently, though ~/.emacs still works) so that they become permanent. The customize interface is one of the few that I have encountered in Emacs with buttons and other controls that make using the mouse, rather than the keyboard, seem like the right way to go.

Searching the internet for "how to do X in Emacs" will quickly lead to lots of different places with suggestions and ideas of varying quality. They will often require evaluating elisp code, which is easy enough to do, but it is a little unclear to me how well that all meshes with a running Emacs session. Petersen quickly describes M-x eval-region (and eval-buffer), but recommends putting code in the startup file and restarting Emacs if something goes wrong, which sounds a little worrisome. Petersen's article on elisp evaluation covers the options more extensively than the book does.

So far, I have not really encountered any major, inexplicable weirdness from evaluating code, so maybe I am overthinking things. I certainly don't want to be restarting Emacs with any frequency; once buffers/windows/frames are set up the way I like them, it is irritating to have to redo all of that. Maybe there is some package out there to save and restore the state; in truth, I would be shocked if there wasn't. But that's something for another day.

Help, movement, and editing

Petersen covers the extensive help system in Emacs, which is something that he says he uses quite frequently. I can only concur that knowing how to find out what a key does, what the keybinding for a command is (if any), what a command does, and so much more is incredibly empowering. The Emacs manual is available, as is the info documentation for many parts of the GNU system, man pages, and so on. I intend to figure out the EPUB reader so I can refer back to the book while wrestling with Emacs in the future.

But, wait, there's more. The "theory of movement" is the next major section, which covers things like loading and saving files (or finding files and saving buffers in Emacs-speak), switching between buffers, listing all of the buffers, killing (closing) buffers, and so on. He strongly suggests switching the C-x C-b buffer listing command to use M-x ibuffer instead. He also thinks that the C-x b command for switching buffers could have a much better auto-complete function, so he recommends using IDO mode (or FIDO mode in Emacs 27+) instead.

There are, of course, a myriad of ways to move the point (cursor) in Emacs: by character, line, word, s-expression, page, paragraph, forward, backward, and probably upside-down too. The mouse can be used (at least in a GUI-window Emacs), as can the arrow keys. The latter has been my downfall, to a certain extent, though Petersen is characteristically sanguine about "cheating" that way; it is something I would like to train myself out of, but not to the point of disabling (or rebinding) those keys.

And, finally, we reach the editing chapter (skipping over plenty to get there). One of the things it stresses is that "killing" text is the main way to get rid of it from a buffer, but that killing is quite distinct from the concept of deleting text as it is in most editors. Except for the single-character delete commands (forward and backward), pretty much all of the other ways to remove text do so by killing it and moving it to the kill ring. As might be guessed, the kill ring stores these kills so that they can be yanked (pasted) elsewhere into the buffer—or into some other buffer entirely.

As with the other parts of the book, Petersen describes the real-world use of the features and tries to point the reader in the right direction to get the most out of them. For example, one could use the region-marking commands to select a region (between the mark and point, in Emacs terms) containing three words, then kill it, but it is much faster to simply do three M-d commands to kill by words; consecutive kills append to the same kill-buffer entry, so the effect is exactly the same. It is tidbits like that, which are scattered throughout the book, that make it so useful.

Remembering said tidbits, commands, key sequences, and so on is an entirely separate problem, of course. I have had an emacs-cheat file, lovingly maintained with vi until recently, since the crash-course days. It has grown by leaps and bounds over the last couple of weeks. I find myself referring to it frequently (from inside Emacs, of course), but there seems to be hope that I am actually committing some of what I have learned to muscle memory. Time will tell.

So far, I have read through two-thirds of the book, while skimming and cherry-picking through the rest. Perhaps my newfound enthusiasm for Emacs (Lisp, ...) is coloring my judgment but I have found the book to be well-nigh amazing. I have some minor quibbles in spots; for example, the whole-line-or-region package that he recommends can be installed easily enough, at least if you add the MELPA repository as he also suggested, but he never mentions that you need to enable the package in init.el (or wherever).

Meanwhile, it would seem that MELPA is where the majority of Emacs packages live today, so why isn't it added by default? That is not Petersen's fault, of course; I should probably take it up with my distribution or with the Emacs project itself. (Ah, as it turns out, Richard Stallman objects to MELPA, so I guess I should bug my distribution—or just ignore the problem and move along.)

Even in the parts of the book that I have read, I have skipped over topics in this review: the undo ring, package manager, searching, tabs, and more. Beware that reading the book can be something of a time sink, as can attempting to apply what has been learned. I find myself pausing more often than I used to, but also generally moving around more efficiently in Emacs; so far, it is hard to see a net win there, but the signs are hopeful. My emacs-cheat file (always visible in another frame or window) is organized in a way that matches how my brain (allegedly) works, so something personalized along those lines may make sense for others.

I did not set out to write an article when I stumbled down this rabbit-hole-strewn path, but, as I got into the book, it seemed like something readers might want to learn about. For now, my goal is to see if I can wean myself away from vi, mostly as a test; I certainly have nothing against that editor and will use it again. For example, I have not even tried Emacs in a terminal, or over SSH, which may necessitate a return to my editing roots, at least temporarily. In the meantime, I am enjoying my exploration of Emacs (and Lisp)—learning new things is always fun.