Irreal

Eli Zaretskii has announced the start of the Emacs 30 release cycle. What that means is that Eli has created the emacs-30 release branch and restricted commits to it to bug fixes that don’t affect low level code. This is the start of the process where what will become Emacs 30 starts undergoing refinement and polish.

Eli says that he hopes to release the first pretest in about a month. After that, barring any show stoppers, the release of Emacs 30.1 won’t be far behind.

If you don’t mind living on the bleeding edge, download and install the emacs-30 branch and report any problems to the development team. You’ll be helping all of us get a better Emacs 30.1 faster by doing so.

I know I always say this but it can’t be said enough: thanks to Eli and the other devs who work so hard to benefit us all. I’d double their salary but it would stay the same.

I’ve been following the discussion on Emacs Devel about moving the excellent which-key app to Emacs core. Moving it to core was non-controversial. The only issue was whether they could get all the which-key contributors to assign their rights to the FSF before the Emacs 30 freeze. Happily, that appears to have happened and which-key will be part of Emacs version 30.

In a sense, it doesn’t really matter. As I’ve said before, the difference between core and third party packages is mostly political rather than practical. Still, there are some advantages to being in core. First, some users install Emacs on minimal systems or have to run old versions for one reason or another so they have to depend on whatever comes prepackaged with Emacs. Second, and more important to my mind, having a package in core aids in discoverability. It’s a lot easier to discover, say, which-key if it’s builtin and doesn’t have to be installed.

Regardless, if you aren’t already using which-key, you should start. It mostly stays out of the way but if you start a key sequence but don’t complete it within a preset time interval, which-key will pop up a menu in the minibuffer with the possible completions. It’s really great because you don’t have to worry about, say, all the rectangle commands. If you type Ctrl+x r and stop, which-key will tell you all the possible completions.

I’ve been using it for years and wouldn’t want to live without it. I’m happy to see it moved to core if only because a few more people will discover it.

Chris Maiorana has an interesting post on using Emacs for creative writing. The TL;DR was that a friend criticized his writing as being too “choppy” and speculated that it was because Emacs made it too easy to rearrange blocks of text. He took that criticism to heart and tried using Libreoffice Writer for his writing instead. The results were the same. It turns out that the problem was his and not his writing instrument. He solved the problem without reference to his editor and returned to Emacs.

It was an interesting story but it got me thinking about professional writers and the mechanics of their writing. Professional writers are notoriously fussy about their writing environment and have strongly held views on what’s right and works for them.

Some—Neal Stephensen and Tess Gerritsen, for example—write their stories in long hand and only later transcribe them with some sort of editor. Stephensen says he types so fast that he doesn’t have time to think carefully about what he’s writing. Gerritsen says she types faster than anyone she knows and that if she wrote on a word processor she would spend her time editing instead of writing.

Others, such as Vernor Vinge, Jerry Pournelle, and Charlie Stross use their editors exclusively. Pournelle, in particular, wrote several BYTE articles on the various editors he used for writing.

I don’t write novels but I do have strong opinions about the proper tools for writing. With all due respect to Stephensen and Gerritsen, two of my favorite writers, I could never write anything in longhand. First of all, my writing is terrible so I have to print, and that is so slow I’d get about 50 words a day done that way. I don’t do too much editing as I’m writing. Sometimes I’ll rewrite a sentence as I’m dong the initial draft but mostly editing happens on separate editing passes. Regardless, every bit of it happens in Emacs.

I’ve been fascinated by the writing process for as long as I can remember. Feel free to share your process.

Daniel de Haas has a post that I really like. In it, he sings the praises of the Emacs idea that everything is a command. If you’re an Emacser that may seem obvious but imagine not being familiar with Emacs and deciding to write an editor. Chances are you’d have a hard coded table that mapped keystrokes to actions or perhaps even some giant switch on key input with the appropriate code right there. That’s not just another legitimate alternative, it a terrible choice but one that the majority of editors make.

For example how would you enable the user to change the bindings if they need or want to? It’s virtually impossible. And it’s not just the basic navigation commands that can’t be remapped. There is no way to define and map alternative commands for more complicated editing commands. All that’s is easy in Emacs because

1. Everything is a command, and
2. Keybindings are kept in runtime editable structures.

In Emacs, even inserting a character into the current buffer when a key is pressed is a command. That means that if the user wants to perform some sort of filtering or translation of text input, it’s easy to do.

It also means, as de Haas says, that with Emacs you have a universal command palette. Every command, and therefore every action, can be brought up in a list to choose from. And it’s easy to combine those commands into a more complex action without knowing more than a modicum of Elisp.

The reddit comments to his post are also interesting. There’s a ton of ankle biting and uninformed commentary but there are also a lot of interesting comments that are on point and worth reading. Take a look at de Haas’ post and, if you have some spare time, the comments. It’s really interesting.

Over at the Emacs subreddit, WarmToiletSeat0 posts an all-too-rare thank you for a part of Emacs that we all take for granted: documentation. Emacs is famously the self-documenting editor, of course, but most of us probably don’t think very deeply about what that means or how it happens.

When I hear that term, I usually think about docstrings. They make it possible to add easily accessed documentation to even your private Emacs code. Done well, as they most often are, a docstring tells you everything you need to know about a function. Like every other Emacs user, I call them up all the time through the help system.

But docstrings are just the beginning. Like every other big project, Emacs has one or more comprehensive manuals that document the system and how to use it. In the case of Emacs, those manuals are available in printed form, online, and—most importantly—as Info files accessible from Emacs itself. That means that an Emacs user can call up the Emacs manual or any of the auxiliary manuals from within Emacs and have the (hypertext) results displayed in an Emacs buffer.

That last phrase is, I think, important. When you call up Emacs documentation, it doesn’t fire up a PDF reader or shunt you off to some other application to read it. The results are right there in an Emacs buffer just like any other.

The point of WarmToiletSeat0’s post is to say thank you to the folks who provide that documentation. Sometimes it’s a developer but other times it’s just someone who steps up to perform a necessary and important function. I’d like to add my thanks to those unsung heroes who do the unglamorous work of documenting our editor and making it better for us all.

Bsag over at but she’s a girl… has an interesting post on what she calls the Emacs from scratch cycle. She’s noticed that she goes through a roughly 3-year cycle of starting with a vanilla Emacs configuration, moving to one of the Emacs frameworks such as Doom, and then back again to vanilla Emacs. It is by no means a waste of time. In each cycle she learns a bit more about herself, her editing needs, and Emacs. As I put it before, it’s like tending a Japanese garden: a lifetime spent moving towards perfection but never achieving it.

In her latest cycle, she decided to resist adding packages unless she was irritated by not having their capability. Once installed, she makes a point of evaluating whether or not they actually improves things and deletes them if they don’t. She was, she said, surprised at how few packages she ended up keeping. I’m sort of like that except that I don’t have her culling discipline. I’m slow to add packages but once installed, I seldom delete them.

Bsag compares the process to making her own clothes. When you do that you end up with clothes that fit comfortably, are exactly the right length, are made from the fabrics you prefer, and even have the pockets exactly where you want them. But, making your clothes is, you know, a pain. It’s a lot of work and sometimes it seems easier to just go out and buy a premade garment.

My innate inertia and, let’s face it, laziness has saved me from this. I started out with a bare Emacs and added configuration items when I found I needed them or discovered something that appealed to me. That configuration has been expanding ever since. As I said, I seldom bother to prune it. Nor have I ever felt the need to declare Emacs configuration bankruptcy and start over. Currently, my configuration is about 2,500 lines so it’s still under control and probably will be for the rest of my life. I hardly ever restart Emacs and when I do it starts quickly so I see no need to change my ways.

Bsag has an interesting perspective. It’s worth spending a few minutes on her post.