Irreal

In response to my post on the best emacs keyboards, Paul Jorgensen has a very interesting post of how he leverages software to turn the standard Apple keyboards into Emacs specific keyboards and make them better suited to his needs outside of Emacs as well.

Oddly, he doesn’t have RSI problems so his changes are simply for keyboard efficiency. His post is interesting because it shows how far you can get with a standard, builtin keyboard through software.

Jorgensen uses a combination of Emacs configuration and Karabiner-Elements to customize his keyboard layout. It’s nowhere near what I’d want but that’s not the point. You can use his strategy to configure your keyboard to your requirements.

The lesson from all this is that you don’t (necessarily) need a special keyboard to make it amenable to Emacs or whatever else you’re using. Happily, I don’t require much more than mapping caps lock to Ctrl, choosing a key for Hyper, and choosing a key for Super. All that’s easily done from within Emacs and standard macOS.

All of this is significant because although there are now plenty of excellent third party keyboards available, many—or most—of us are using laptops as our main computers and often don’t have the option of using third party keyboards. Being able to use software to reconfigure our standard keyboards to our liking is a huge win.

If this sort of thing interests you, take a look at Jorgensen’s post. As I said, you don’t have to make the same choices that he did. His process will allow you to make just about any configuration possible.

Eli Zaretskii has announced that the first pretest for Emacs 30.2 is now available for testing. That’s great news. It’s nice to see that development is proceeding apace with the planned bug releases between the—more or less—yearly major releases.

As I always say, if you don’t mind living on the edge a tiny bit, download and test this new release. And as I also always say, thanks to Eli and all the other developers who give so much to our community. They’re real heroes and deserve the gratitude of us all.

One of the killer features of Journelly for many of us is that Journelly’s data is stored as Org Mode markup and that this data is easily synced to the iCloud so that it can be shared among all your devices, including a Mac. That means that you can display and edit the Journelly data just like any other Org file.

It also means that you can make an Org Mode template to add entries to the file right from your Mac. When you do, the entries will show up in the Journelly app just as you’d expect. That’s significant because it means you can take Journelly notes from any of your devices.

Early on, while the app was still in beta, Jack Baty wrote about a template he was using for just this purpose. Ramírez, of course, had his own version. A limitation of both versions was that they didn’t capture the location and weather information. Baty remarked that it shouldn’t be too hard to add that and I remember thinking it was something I should do as soon as I got a chance.

It turns out that it’s a bit harder than I thought. Ramírez has a new post that shows how to do it. Part of the problem is that access to the weather APIs on the Mac require an API key and there’s apparently no easily accessible API for location so Ramírez had to use third party apps for both of these. Even so, it didn’t take much code and now he has a template that captures data and displays it in Journelly just as if it had been entered there in the first place.

If you’d like to try this out, the code is available on GitHub here.

One of the strengths—or weaknesses, depending on your point of view—of Lisp is garbage collection. That means that memory no longer in use is automatically collected and made available to the system without depending on the programmer to release it the way we do in, say, C. Of course, that comes at a cost. Garbage collection can block other operations while it’s running. That’s especially true in the single threaded Emacs.

One often sees complaints about this in the various forums. There’s all sort of advice about what to do. Some say you should set the garbage collection threshold (the amount of collectible memory) high so that garbage collection isn’t triggered as often. Of course, that means that it takes longer to collect the unused memory.

Another suggestion is to set the threshold low so that unused memory can be collected quickly. That means, though, that garbage collection is run more often. Depending on your workflow, either—or possibly both—of these strategies may work well for you.

There’s a third, arguably better, strategy: only garbage collect when the system is idle. That’s facile advice, of course, because it begs the question of how you know when the system is idle. There’s a useful heuristic. If the system has been idle for x seconds it will probably continue being idle long enough for a garbage collection cycle. The question then boils down to the proper value for x.

Jack Jamison believes x should be small and uses 1.2 seconds in his implementation of this strategy. He says that he’s had excellent results with that value. The older GCMH system uses 15 seconds.

I’ve been using GCMH was several years and can’t remember having any garbage collection issues since I started. GCHH lets you configure the idle time but the 15 second setting has been working well for me so I’m not inclined to mess with it.

In any event, if your Emacs is experiencing garbage collection delays it’s worth trying this strategy. If you want a simple prepackaged solution, GCMH is for you. If you want to keep everything in your init.el and avoid external packages, take a look at Jamison’s post to get started.

Back before I became an Emacser, a friend who was an Emacser said that I shouldn’t worry about the Emacs keybindings because I could configure them to be whatever I want. I remember thinking that that would be disaster. After all, what would I do if I were using Emacs on someone else’s computer or even setting up a new computer.

Now, of course, I have a very individualistic configuration that makes working on someone else’s computer uncomfortable. Uncomfortable but not impossible. That’s because although I have all sorts of specialized editing commands, I’ve left the “vanilla” editing commands—cursor movements, file visiting and saving, and other standard operations—alone. That means that if I use someone else’s Emacs I can edit successfully, if not optimally, as long as the guest Emacs also didn’t mess with the standard bindings.

That’s why I’m not entirely sympathetic to The MKat’s post on how to unset default key bindings. She’s got a lot of great advice on how to delete keybindings and I agree that it’s useful information to have. My objection is to the notion that you should delete bindings that you don’t like.

Just yesterday, I discussed how modern keyboards aren’t optmal for Emacs so it’s natural to want to fix that somehow. Yesterday’s post suggests some ways of doing that but none of them involve changing default keybindings.

Sure, some folks have special needs that make one binding or another difficult but in general, I think it’s a bad idea to be messing with them. Of course, this is Emacs and everyone can adjust it to their liking. I’m not arguing with that. I’m only saying that if you stay with the defaults it will be easier for you to use an alien Emacs.

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.