Irreal

A month ago I opined that no true Scotsman Emacser would view anything but the Space Cadet Keyboard as the apotheosis of keyboards for Emacs users. I was promptly schooled that, to the contrary, most Emacs users today have no desire for a Space Cadet Keyboard. I remain firm in my desire for one but I bow to the prevailing view.

But if the Space Cadet Keyboard is not the pinnacle, what is? The TL;DR is that no one knows. Everyone, it seems, has their own idea of the ideal Emacs keyboard. Over at the Emacs subreddit, yibie asks what keyboards will people be using for Emacs in 2025. The striking thing is that there are almost as many answers as there are comments. Everyone appears to have their own preferred keyboard that they swear by.

I remained convinced that the most important thing in choosing an Emacs keyboard is mappings for Hyper and Super. Every modern keyboard has Ctrl and Meta (as Alt) covered but there is no standard way of mapping Meta and Super.

In any event, if you have your own views, feel free to jump in and share what you’re using.

Marcin Borkowski (mbork) has a nice post on the Emacs substitute-command-keys command. The TL;DR is that it’s a way of mapping a command name to its keybinding. I’ve long been familiar with it but only in the context of Emacs Doc strings. For example, here’s the Doc string from one of my custom macros:

  "Convenience macro to generate a key sequence map entry
for \\[prettify-key-sequence]."

the \\[prettify-key-sequence] is mapped to whatever the current binding for prettify-key-sequence is. It’s nice because I can change the binding without having to worry about updating the documentation.

Mbork’s post tells us that my use above is really just a special case of a more general facility: substitute-command-keys. You can programmatically convert a function name to its binding by calling substitute-command-keys.

I’m not sure where you’d want to use this other than in a Doc string (or maybe an Org doc) but I’m ready to be educated on the matter. I can’t remember where I learned about using \\[...] in the Doc string. It was probably from seeing it in some function in Emacs core. One thing for sure, it’s not easy to discover without looking for it explicitly or stumbling across it like I probably did.

In any event, this is a useful thing to know. It’s a great example of how Emacs is self documenting.

Over at the Emacs subreddit, ismbks asks about drawing tools for Emacs. If you’re like me, the only thing that comes to mind is artist-mode with possible export through ditaa. That combination has always met my needs but it is pretty rudimentary and mostly confined to block diagrams.

The comments have some other solutions. On really nice example is AKIYAMA Kouhei’s Emacs Easy Draw. It’s very interactive and has nice line drawing capabilities. Take a look at the demo on its GitHub page to get an idea of what it can do.

Another commenter recommends PlantUML, which is good for flow diagrams and fancy block diagrams. It’s a markup application rather than interactive if you prefer that way of working.

Of course, all these applications are meant for engineers needing to draw engineering diagrams and not for artists who want to do serious digital art. Emacs is probably never going to support that sort of thing and why should it? After all, there are applications specialized for that and it’s hard to imagine a need for doing it from within Emacs.

Once you discover the utility of having multiple windows in a single Emacs frame, the question of how to switch between those windows arises naturally. Emacs, of course, has you covered. You can use Ctrl+x o to cycle between windows. That’s great if you have only a couple of windows in a frame but it becomes tedious when there are multiple windows. That, of course, happens often once you get used to making maximum use of Emacs.

Marie K. Ekeberg over at TheMKat has a solution. It’s a nice solution in the sense that it’s built into Emacs so you can use it without adding anything extra. That solution is windmove. Ekeberg didn’t like the default bindings but, as she says, it’s easy to change them to whatever is comfortable for you.

I used windmove for a while but I have since moved to ace-window, a wonderful app from abo-abo that, when invoked, labels each visible window with a number that you can use to select that window you want to move to. I’ve bound it to Ctrl+x o so I didn’t have to learn a new binding. The nice thing is that if there are only two windows—my usual situation—ace-window will simply switch to the other without further ado.

When I brought up the ace-window repository while writing this post, I noticed that there are a bunch of possible actions available. I never use any of them except switching but you may find some of them useful.

The TL;DR is that if you routinely have more than two windows in a frame, ace-window is a must have app. I’ve been using it for years and wouldn’t want to live without it.