Irreal

Protesilaos Stavrou (Prot) has posted a really nice and useful video on something that I’ve been struggling with off and on for many years. The problem is I often want—usually several times a day—to pop up an Emacs buffer and run some command like org-capture. There’s no problem with that, of course, if I’m in Emacs but what if—as is often the case—I’m in some other app?

The basic strategy is to call emacsclient with a -e parameter specifying whatever Emacs command you want to run. The devil, as they say, is in the details. First of all, you have to arrange for an Emacs frame to hold the popup menu and then you have to arrange for it to be deleted when you’re done.

Prot provides a complete, easy to understand framework for all of this. He defines a macro that lets you specify an Emacs command for a popup. You need only specify an OS level key binding to call the function and identify a hook function that will call the function to delete the popup frame when the command is done—most other situations are handled by the code generated by the macro.

I’ve tried to solve this problem with everything from some Applescript to Alphapapas yequake. I’m currently using yequake and it works well for me but if I were starting out I’d definitely take a look at Prot’s code. It’s self contained, easily understandable and hackable, and can be adjusted to your particular use case. All you need is a way of binding an OS level key sequence to the appropriate command. If you need to execute Emacs commands from outside of Emacs, take a look at Prot’s code.

After my last post on ideal Emacs keyboards, here’s a reminder of what reality actually looks like. When I used to see pictures like that, I thought they were amusing but couldn’t really relate. Now my own laptop keyboard is showing the same signs.

Oddly, it’s not the Ctrl key that’s showing wear but the Meta key, otherwise known as ⌥ Opt in Apple land, that’s showing wear. That’s probably because I have Caps Lock bound to Ctrl but I use both it and Ctrl depending on the situation. That means that Ctrl gets only half the use it otherwise would.

The other key that’s showing wear is my left ⌘ Cmd key. For Emacs purposes that’s bound to Super but I rarely use it for that. Its wear is probably due to its central role in Apple navigation.

When your Emacs keys begin to wear out, it’s probably a sign that it’s time to upgrade your laptop—or get a new keyboard if you’re using a desktop. I actually have a new laptop ready but it uses the new M-series processors so upgrading is not as easy as I’d like. Still, it’s obviously time to get on with it.

If you’re a real Emacs aficionado then you probably think that the ideal—indeed, the only acceptable—keyboard for Emacs is the Space Cadet Keybord. I’m sympathetic to that view and would love to have such a keyboard available to use. Sadly, that’s not likely to happen so we’re reduced to choosing from one of the actually available keyboards.

They’re all basically the same but there is enough difference to allow one to start with a keyboard that can be customized. Over at the Emacs subreddit, drojd specifies their ideal Emacs keyboard layout. I agree that it’s pretty nice and, indeed, it’s pretty close to what I use on my Mac keyboards.

The main problem¹ for us Emacs users is finding a reasonable mapping for HYPER and SUPER. I’ve been through several iterations for these mappings. The problem, for me, is that macOS keeps appropriating the keys I use for those modifiers. Doubtless, other operating systems have similar problems. My current configuration has worked for several years so I’m hopeful that I won’t have to learn new bindings anytime soon.

When I look at the diagram in drojd’s diagram what strikes me is that it’s really only HYPER and SUPER that need to be specified. To be sure, I’d like a Space Cadet keyboard but any modern keyboard will do as long as you can make reasonable mappings for HYPER and SUPER.

One can—just barely—get by without HYPER and SUPER but why would you want to? My main use for them is not for whatever their defaults bindings are but to expand the number of available bindings for my own commands.

Chris Maiorana has an interesting take on counting words. He’s a writer and like all writers, he’s interested in how many words he’s written in the current session. His reasons for wanting that count boils down to it providing a measure of his daily work and, perhaps more important, helping him to know when to stop.

But, he says, there are some problems with word counts as usually implemented. The most important concerns the way that many (the majority of?) writers work. They like to reread and edit what they wrote in their last session. That means that words may be subtracted as well as added. What’s really needed, he says, is a count of the number of words that have changed.

His solution for that is to use git diff to find out how the text has changed and count the number of changes. It’s a bit fussy as you’d imagine but really pretty straightforward. Take a look at his blog post for the code and details.

I love this idea but I’m not sure it’s for me. For long form writing, what I’m mainly interested in is progress so knowing my current word count—regardless of additions or subtractions—is what’s important to me. For short form writing, such as this blog, I really care only about the total word count since I almost always complete a post in a single session—not counting a final editing pass just before I publish it—and I’m never in any danger of burning out while writing a single post.

Still, if you’re a writer and interested in measuring your work rather than your progress, Maiorana’s hack may be just what you’re looking for. You’ll need to keep your text in Git but you should be doing that anyway.

For those of you interested in the history of Emacs, how it all started, and where it got its name, here is an original document from 1979 written by Richard Stallman that describers the new Emacs system.

I found the paper in this this post that references an update to the original paper. EricIO added a pointer to the orginal paper that I’ve linked above. There’s a lot of good information in the comments including a Twitter thread that discusses how Stallman eventually settled on the name Emacs.

For the day-to-day programmer, none of this matters a bit but for those of us who care about our backstory and how we got here, it’s a nice addition to the narrative. The whole thing—other than the actual paper—is short so take a look if you’re interested in our history.