Irreal

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.