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.