Irreal

Raymond Zeitler over at Ray on Emacs doesn’t use version control for his “non-public” files so when he had a problem with his .emacs file, he didn’t have any backups except for the single last version of a file that Emacs will make automatically if you have backups enabled. That, apparently, was enough to recover but Zeitler resolved to do better.

What he did was to replace .emacs~ with .emacs.~1~, which causes Emacs to create a numbered sequence of backups rather than simply overwriting the last one. Reading his post reminded me of my backup scheme, which I haven’t thought about in years because all my files—except autogenerated ones—go into Git.

My backup scheme is a little different from Zeitler’s because I’ve set mine to keep only the last two backups. That way, my file system doesn’t fill up with long forgotten and unneeded backups. Even so, there were a lot of backups—some for files that don’t even exist anymore—taking up a lot of space. I deleted them all and started over.

I don’t claim that 2 is the right number for everyone or even for me. It just seemed like a safe number in case something happened with Git. Happily, I’ve never had to use the backups, which is why I’d mostly forgotten about them.

One thing for sure, you need to be religious about either saving your files to a version control system or configuring the Emacs backup system to automatically save some number of backups for you.

Chris Maiorana has a lovely blog post in which he makes the case that Emacs users are a different breed. He starts with the quotidian observation that you can be pretty sure that a Vim or VSCode user is either a software developer or in a closely related such field such as System Administration or DevOps. Emacs users, on the other hand, could come from almost anywhere.

This is a point that Irreal is fond of making. I’m fascinated by people from outside the software field who use Emacs as an essential part of their workflow. Their stories always illustrate the power and flexibility of Emacs to solve problems even if they aren’t about software and engineering.

What distinguishes Emacs users, Maiorana claims, is their love of tinkering and the blurring of work and play when they’re using Emacs. As he puts it

Emacs could be more than a text editor. It could be an organizer, a scratchpad, a dictionary, a canvas, a database, a calendar, an email client, and much more. What should have been work started to feel like fun.

Maiorana says that Emacs users don’t care primarily about the usefulness or user friendliness of Emacs; it’s the opportunity for tinkering that attracts them. I think he has this part backwards. Emacs users surely do love to tinker but the attractive thing about Emacs is that your tinkering can turn it into the exact tool that you need. That’s true even if the tool you need has nothing to do with software or its siblings.

Emacs is, in fact, the perfect piece of software. Not only does it indulge our urge to tinker and have fun but also allows us to turn that tinkering into the precise tool we need. Not just once but as often as we desire as our needs change. With Emacs, the fun never ends.

One of the things that we Emacers hear with tiring frequency is that Emacs is moribund, old technology loved only by graybeards stuck in the last century. In fact, as actual users know, Emacs is undergoing constant development and is often the first to offer new features that the other editors copy. The most salient examples are Org mode and Magit but there are plenty of more recent examples.

But don’t take my word for it. Over at the Emacs subreddit, gonstrider has a short post relating his experience with all of this. He’s been using an unnamed editor—you’ll have no problem figuring out which one—that keeps having weekly updates that seem to make things worse each time. So he jumped in the deep end and downloaded and built Master (Emacs 32) fully expecting to find lots of broken things.

It didn’t turn out that way. He was, in fact, surprised to discover that almost everything worked well. The only problem he had was evil on Windows and he solved that by simply upgrading evil. As for the rest, he found that Emacs was super-responsive and all the functionality that seemed laggy in that other editor was snappy in Emacs.

There are two lessons here. The first is that Emacs, far from being moribund, is undergoing continuing development and introducing new features. The second point is that Emacs is, unlike some of its competitors, continuing to produce upgrades that simply work and don’t make their users crazy.

Very shortly, we should see the release of Emacs 31 but work on Emacs 32 is already ongoing and amazingly stable for what is, after all, alpha software. The next time someone tells you that Emacs is old and moribund, refer them to gonstrider’s post.

Marcin Borkowski (mbork) does a lot of writing and, of course, uses Org mode for most of it. The hard part, he says, is not the writing but the editing. In particular, he’s talking about the emphasis markup. If he wants to write a word or region in bold, that’s easy. He merely starts and end it text with a star. Making a word or region bold after the fact—in the editing phase—is more difficult. You have to locate the beginning of the text, add a star, move to the end of the text, and add another star.

Mbork, of course, soon discovered the solution: org-emphjasize. All you need to do is highlight the text and specify the markup character. The problem is that the binding for org-emphasize, Ctrl+c Ctrl+x Ctrl+f, is difficult to type. Mbork solved that writing a function to call org-emphasize with an argument * to cover his most common use. But then he bound it to Ctrl+c Ctrl+x Ctrl+8, which strikes me as just as bad, although you don’t have to specify the *.

My solution for this is to use surround.el that I wrote about here and Bozhidar Batsov wrote about here. I have it bound to Hyper+’ so it’s easy to call. I suppose you could even do as mbork did and write a specialized function for a heavily applied use case.

One thing for sure, mbork is right about markup being harder to deal with when editing.

Update [2026-08-19 Wed 12:21]: Added link to mbork’s post.

Protesilaos Stavrou (Prot) has another nice video on something that I was vaguely aware of but had never used: conditional abbreviations. As most Emacers know, you can define abbreviations that will expand into another, usually longer or more complicated, string. It can save a lot of time and you can set them to fire automatically or when Tab is pressed right after the abbreviation.

What’s less well known is that these abbreviations can have properties and one of those properties is to specify a function that will tell Emacs whether or not it should expand the abbreviation. Prot gives a few examples of this. In one example, he wants “Welcome” to expand to a French greeting but only if he is using one of the French input methods. Another example expands an abbreviation only if he’s in a certain directory or one of its subdirectories. A third example expands an abbreviation only if a certain minor mode is active.

Those examples might seem like they’d be complicated but they are, in fact, simple, almost trivial. In the call to define-abbrev, you simply give the name of the deciding function in the :enable-function clause. Check out Prot’s video for the details.

I use several abbreviation systems—including abbrev—but this capability in abbrev is especially nice. It’s easy to use and you can make the firing condition as simple or complex as you need it to be.

Prot’s video is 14 minutes, 33 seconds so it should be easy to find time for it. As with all of Prot’s videos, it’s worth the time.

Update [2026-08-19 Wed 12:29]: Added link to post and video.

Srijan Choudhary likes desktop-save-mode but he wants a slightly different behavior. He likes having his session configuration saved but he usually doesn’t want it restored. He wants to restore it only when he closed it by mistake or forget do something in the last session. Then, he wants to restore it by hand.

He could, of course, do this by disabling desktop-save-mode and calling the save and restore functions manually. The problem with that solution is that like most of us Choudhary would forget to do the save.

But this is Emacs so Choudhary was able to roll his own solution. That solution does the automatic save, as usual, but the restore function is disabled at system startup. Instead, the last save is added to a list of the last 5 saves. When he wants to restore a session, he’s presented with the list and can choose the save that he wants.

This is another great example of how Emacs lets you have it your way. His code is a little complex but there are a lot of desktop save peculiarities to account for. If you’re like me, you probably aren’t interested in this capability but that’s the point: even if you’re the only one who wants some functionality, Emacs will let you have it. This capability is something no developer is likely to anticipate so it provides another example of the superiority of Emacs’ method over the typical extension system provided by other editors.

Update [2026-08-10 Mon 10:52]: Added link to Choudhary’s post.

Protesilaos Stavrou (Prot) has another excellent video. This time it’s on it’s on the Emacs speedbar and its Emacs 31 upgrade. The TL;DR is that as of Emacs 31, you can configure the speedbar to be displayed in a separate window instead of a separate frame. The video is 15 minutes, 39 seconds so it should be easy to find time for it.

The placement of the speedbar matters a lot to Prot. He found the speedbar to be unusable when it was displayed in a separate frame because it was difficult to deal with the two related frames. It’s absolutely impossible for me to deal with because I run Emacs as a full screen app so the speedbar is in another workspace and I have to switch to that workspace to see it.

Now that the speedbar can be displayed in the same frame, Prot finds that it can be useful when dealing with large projects with many files. His video is mostly concerned with showing how the speedbar works and what you can do with it.

Lots of people love speedbar-like applications and swear by them. I, however, have never been able to warm up to them. These days, I don’t work with large projects and perhaps I’d feel differently if I did but mostly they just seem like noise to me. Even Prot says he doesn’t use speedbar for his smaller personal projects but that it can be useful for larger, multi-file projects.

My recommendation is that if you don’t already strong opinions on the matter, give the speedbar a try when Emacs 31 comes out and see if it works for you. There are plenty of informed opinions on both sides of the issue so there’s no right answer, just what works for you. As always, Emacs will let you have it your way.