Irreal

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.

If you’ve been around Irreal for as little as a few months, you know that I’m a fan of Charles Choi’s “Casual” utilities. They’re all basically the same. They add a transient menu to Emacs utilities such as Calc, Isearch, Info, and others so that you can have access to the more obscure subcommands of the utilities without having to remember key shortcuts that you hardly ever use.

I’ve found the Calc and Casual Info menus especially helpful since they have lots of subcommands that are useful but that I don’t use all that often. Others may find some of the other Casual menus useful.

Choi started out with the Isearch and Calc packages and probably didn’t realize that the idea could be extended to many other Emacs subsystems. Now that these packages have been a success, Choi realized that those early packages weren’t named in a manner consistent with the later ones. He therefore has announced some name changes. If you aren’t using the Calc or Isearch packages you have nothing to do. If you are, you will have to update your configuration to reflect the changes.

The plan is that the changes will occur on [2024-06-16 Sun] (that’s THIS Sunday) so you’ll need to have your configuration in place after that. I’ve updated my init.el to reflect the new Calc name but it’s still commented out. Given that all goes as planned, I’ll uncomment the new configuration on the 16^th, evaluate it, and be up to date.

Gene Goykhman, like a lot of Emacs users—or simply computer users, for that matter—hates dealing with fussy details while working on his computer. One of his complaints in particular is that there are too many confirmations in some of his frequent tasks.

For example, when quitting and saving an Ediff merge, he has to respond to two separate confirmations. His solution was to write a wrapper function that replaces the confirmation queries with #’always. It’s pretty simple code and easily understandable. He binds it to a keystroke to unconditionally quit whatever function he wants to quit without the bother of confirmations.

This is yet another example of the difference between Emacs extensions and the plugins used by other editors that I wrote about previously. You almost certainly couldn’t make this change with an editor that relies on plugins.

In any event, if you’d like to get rid of some of the superfluous confirmations in your Emacs workflow, give Goykhman’s post a read.

Just a quick note to share something that I’m just learning after more than 15 years of using Emacs. I am, of course, aware that Viper and Evil are modes that emulate the Vi family of editors. It’s a way of letting immigrants from Vi/Vim retain their muscle memory while enjoying the superior working environment of Emacs.

I had always assumed that Viper is an older emulation that has since been replaced by Evil. That’s sort of correct but not quite precise. Over at the Emacs subreddit, CorysInTheHouse69 asks why, given that Viper is builtin, people prefer Evil over Viper. The answers surprised me.

It turns out that they actually have different aims. Viper is a Vi emulation while Evil is a Vim emulation. Unless you’re the type of person who prefers the original Vi to the “new-fangled” Vim and its siblings—and there are such folks—you probably want Evil, which offers a very faithful Vim emulation.

As a side note, several of the respondents note that the distinction between built in and third party packages is more political than practical these days. As I wrote the other day, Emacs makes no distinction between code that is built into Emacs and that which is added on. It can not, in fact, tell the difference. It is, as they say, turtles Elisp all the way down.

Regardless, if you, too, were ignorant about the different purposes of Viper and Evil, now you know.