Irreal

As most of you know, Irreal doesn’t think much of editor-connected bling. We much prefer simple efficiency to flashy accouterments that, in the end, simply get in the way of a decent editing experience. That’s true even though they can, arguably, make it easier to get started with a new editor.

It feels a little odd, then, to be writing favorably about these reformatted Emacs documents that, while they have the same content as the official documents, have been reformatted to look a bit nicer and, more importantly, be easier to navigate. It’s probably not accurate to describes the results as “bling” especially since the point of the change is better navigation.

The two major changes are a sidebar that essentially recapitulates the table of contents so that it’s easy to get an overall view of the document and an improved search function that makes parsing the search results easier.

Irreal does think that these documents are a worthwhile addition to the Emacs document stack and wouldn’t object if, arguendo, they were adopted by GNU. Still, the Irreal bunker is probably going to continue to use the “official” documents but doesn’t object if others make a different choice.

The documents that are available are:

• The GNU Emacs Manual
• The GNU Elisp Reference Manual
• The Org Manual
• The AUCTeX Manual
• The Magit Manual

Take a look at one or more of them and see what you think.

Charles Choi has another Casual app on offer. This time it’s a comprehensive set of menus, Casual EditKit, that capture the various editing commands. On the one hand, these are commands that you really need to know to become proficient with Emacs. On the other hand, as Choi says, the menus serve as a means of discovering those commands.

The problem is that Emacs has such a rich set of commands for editing text that it can be hard to learn them or even know that they exist. For example, I am always seeing comments from people expressing surprise about the transpose-chars and transpose-words commands. I use them everyday and wouldn’t want to live without them, yet there are lots of folks who don’t even know they exist. There are a bunch of other transpose commands that I don’t have bound but that I know exist so I can invoke them—with the help of fuzzy command completion—as named commands when I need them.

This all works because I know these commands exist and it’s not hard for me to invoke them even if I don’t remember their bindings or they have none. The advantage of Choi’s Casual EditKit is that helps you discover these commands and once you know they exist, they’re easy to invoke even if you can’t remember all the details.

Choi just announced Casual EditKit so I obviously don’t have any experience with it but my snap judgment is that its main benefit is teaching a new user what editing commands are available. But, in the long run, every user is going to have to learn those commands. Still, I suppose the menus could be useful for little used commands such as, say, the rectangle commands.

In any event, Casual EditKit is a welcome addition to Choi’s wonderful collection of Emacs menus.

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.