Irreal

Over at the Emacs subreddit, surveypoodle asks a perennial question: what are the best keyboards for Emacs? He points out that Emacs pinky seems to have appeared rather late in the editor’s history and speculates that that’s because the keyboards originally used with Emacs were better suited for it than modern keyboards that make many of the bindings awkward. He’s asking what modern keyboards are best for dealing with RSI.

If you’re interested in an answer to the question, see the comments to surveypoodle’s post. There are all sorts of suggestions. Reading through them, I realized that I didn’t care.

I used to yearn for a reincarnation of the Space Cadet keyboard—okay, I still have some vestigial urges—but I realized that these days I do virtually all my work on my laptop. I’m guessing the same is true many of us. Regardless, the use of a laptop pretty much makes the choice of a keyboard for you. Sure, you can use a third party keyboard but unless you’re always working at (the same) desk it’s just too much trouble. As I’ve said before, I do a lot of my work on the couch so an external keyboard isn’t a practical choice for me.

What to do? As much as it has become a cliche, Emacs pinky—or more generally Emacs induced RSI—is a real thing.The best solution I’ve found is some simple keyboard modifications. I’m using a MacBook Pro so keyboard firmware modifications aren’t an option. What I can do, though, is arrange for the modifier keys I use the most to be easy to reach. Two of those, Ctrl and Hyper are, configurable from within Emacs or macOS. The Meta key is bound to Alt by default so there’s nothing to do there. What all this means is that binding Ctrl to caps lock and Hyper to ⌘ Right Cmd, I can use my thumbs for Meta and Hyper and that Ctrl is an easy reach for my pinky.

I know that a lot of you are doing the same or similar things. If you’ve got a better solution, leave a comment.

Courtesy of JTR from The Art Of Not Asking Why, here’s a handy tip for dealing with window placement when bringing up a Dired buffer. There are two problems.

The first doesn’t really concern window placement. Most often JTR wants to bring up a Dired buffer for whatever directory he’s already in. The easy way to do that is to use dired-jump (bound to Ctrl+x Ctrl+j) to open a buffer in the same directory as the current file.

The problem with that is that it opens the Dired buffer in the current window. JTR doesn’t want that. He wants to open Dired in some other window so that he can see his current file and the Dired buffer. The answer to that is simple: just ask Emacs to open Dired in another window. There’s a general protocol for doing that. Simply use Ctrl+x 4 Ctrl+J to call Dired. That will open Dired in the same directory as the current file but in another window.

The Ctrl+x 4 … works for a lot of commands. I use it to open files or buffers in another window several times a day. I used to consider it an esoteric maneuver but now I use it all the time. You can also open your windows in another frame by using 5 instead of 4.

The 4/5 protocol doesn’t work for all commands but it does for a lot of them. It’s a real time saver that I use repeatedly. It’s well worth internalizing.

Charles Choi makes an astute observation about the Emacs initialization file from the point of view of the new user: there’s no obvious way of loading it or even knowing that it exists. The problem is especially acute on the Mac where the File → Open menu uses the Mac file loading routines that don’t show dot files. Not very helpful even if you know the name of the file.

Choi is surprised that this far on the problem hasn’t been fixed. It’s hard to argue. On the other hand, I don’t remember having this problem. I have no memory at all of how I overcame it but I and thousands of others have. That doesn’t mean that the problem isn’t real, though.

Choi offers a solution. It’s a simple function that loads the init file even if it hasn’t been created yet. His idea is that the function would be builtin and automatically available to the new user.

Of course, the problem is how does the new user discover this function, or for that matter, what to do with the init file once it’s loaded. It seems to me that at the very least there needs to be some instructions on the startup screen—you know, that screen we all turn off as soon as we learn how. That would help but it’s probably not enough.

What’s really needed is a new-user file that explains how to get started. It could be linked from the startup screen. It wouldn’t need to be long or complicated; just enough to bootstrap the new users and point them to the tutorial.

One thing for sure: Choi is right. It’s really harder than it should be for a new user to learn enough to get up to speed with Emacs.

Over at the Emacs subreddit, sebhoagie has a short post that some of you may find useful. Sebhoagie really likes narrowing and uses it all the time. Sometimes, though, the narrowed code refers to code outside the narrowed region and he occasionally wants to reference it and then return to the narrowed region.

That’s not a big problem of course. Just widen, search for the referenced code, highlight the original narrowed code, and renarrow. Of course there’s a bit of friction and if you need to do it often it can become a burden.

Sebhoagie has a writeup that explains his solution. The TL;DR is that he wrote a function that narrows to a region but when you widen, it remembers the narrowed region. If you narrow again (using his function) it will renarrow to the previous region and forget the saved region parameters. If you think it through, that does exactly what you want. When you’re finished with the narrowed region you simply widen in the normal way (with widen) and everything is reset.

My solution is to use Artur Malabarba’s narrow-or-widen-dwim that almost always does exactly what I want. Take a look at Malabarba’s post to see how it works. If you’re not using it, you’re definitely working too hard. Still, you may find sebhoagie’s useful. If you have a similar need, his code is a nice companion to Malabarba’s.

Narrowing really can be a superpower as sebhoagie says and it’s worthwhile making its use as easy as possible.

MarchZealousideal543 over at the Emacs subreddit asks a familiar question: Is it really feasible or even possible for a non-programmer to use Emacs productively? I know I write about this a lot but I find the subject fascinating. MarchZealousideal543 got steered onto Emacs by asking some AI for suggestions and apparently Emacs was the overwhelming recommendation.

There’s nothing very interesting about such questions, of course; the interest is in the comments. There’s the usual ankle biting and nonsense but a lot of the comments are excellent and tell stories of how people from all walks of life—even someone in construction—use Emacs to run their lives, careers, or businesses.

The one thing that many of them say, though, is that you should expect to spend a few weeks getting up to speed with Emacs. Those of us who have been using Emacs for decades and still consider ourselves barely up to speed can only smile. Nevertheless, they all say that the startup time is worth it and that you will soon become proficient.

The other story that came up more than once was how the secretaries at the MIT were introduced to Emacs and given a small write up on how to configure it. Because they didn’t realize they were programming, they soon were soon automating their workflows.

If, like me, you like reading about non-technical people using Emacs, take a look at this reddit post.

If you’re one of those brave folks who doesn’t mind browsing the Web from within Emacs, I just came across a package that may interest you. It’s emacs-websearch a small utility that lets you specify a term, search for it on the web, choose one of the results, and open that page in your Emacs.

That may sound a little complicated but take a look at the animated GIF at the link. It seems like a pretty nice workflow. Right now, it supports Duck Duck Go and Google but looking at the code, it would be easy to add your favorite. You can choose between using the xwidget toolkit and eaf-open-browser to display the Web page.

This is one of those small packages that mainly scratches the author’s itch but can still be useful to the rest of us. Take a look and see if it might work for you.