Irreal

Álvaro Ramírez, author of Journelly and many other useful applications—a lot of them Emacs based—has a new post about a basic Emacs operation: changing focus to another window. Ramírez and I basically agree about things like this although he stubbornly refuses to admit the superiority of my method of indicating the window that has focus.

Now he has a slightly different problem. For technical reasons that you can read about in his post, he wants to be able to switch to a window in another frame. The other-window command, bound to Ctrl+x o by default, doesn’t consider windows in other frames but, of course, there’s a command for that: next-window-any-frame. That turned out to be exactly what Ramírez needed and he simply bound it to Meta+o, which is where he had other-window bound.

Like Ramírez, I seldom use more than one frame so I didn’t know about this command. If you often have more than one frame going, you may find it useful if you’re not already using it. If you’re an ace-window user, it will consider all frames by default but you can adjust this with aw-scope.

Great news! Sean Whitton writes to announce the release of Emacs 31.1 RC1. This is the final step before the formal release of the Emacs 31 series. Whitton remarks that the developers are hoping that RC1 will be the only release candidate. I take that as a measure of their confidence in this trial release. Unless any breaking problems pop up, we can expect the official release of 31.1 imminently.

As always, we should offer up a word of thanks for the hard work of the maintainers and all the developers who have toiled so hard to bring us this latest release. If we find ourselves in the same bar as one of them, the drinks are on us.

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.