Irreal

If you’re one of those people who obsess about making every Emacs operation as fast as possible, James Dyer has quick tip for you. Dyer uses Dired a lot and one of his common operations is to search for a file in a Dired buffer using isearch-forward and then open it. Of course, he wants to make this operation as efficient as possible so he objects to the fact that he has to type Return twice: once to terminate the search and then again to open the file at point.

Dyer’s tip is a way of completing the search/open operation with a single return. He does this with a bit of advice to the isearch-exit function. Check out his post for the details.

Dyer admits that this is a small thing and even makes a back of the envelope calculation of how long it will take him to recoup the time he spent implementing the solution. Of course, sometimes it’s the journey and what we learn along the way that’s important and this is probably one of those times.

Regardless, if you find yourself often searching for and opening a file in Dired, you may find Dyer’s tip useful. At least you will if you care about saving a keystroke with each operation.

When the Eagles disbanded after a particularly contentious Long Beach concert where Glenn Frey and Don Felder almost came to blows, Don Henley quipped that the band would get back together when Hell freezes over. Fourteen years later the band did reunite and released their new album, Hell Freezes Over.

I was reminded of that when I read Bozhidar Batsov’s latest post on Rediscovering Vim. Most people don’t know that, like me, Batsov used Vim early in his career. He apparently didn’t stay with Vim too long because of its really hideous extension language. I was less interested in customizing my editor back then and stayed with Vim for many years.

Batsov isn’t, of course, abandoning Emacs. He just wants to “rediscover” Vim and see what he can learn from it. He started out with Neovim, which, apparently, most developers in the Vi camp are using now. But he dropped back to Vim so that he could develop his own configuration just as he had with Emacs.

Batsov likes the way Vim has the notion of “text object” and a uniform way of dealing with those objects. As I’ve said before, that’s what makes it so easy to learn and use the Vim key sequences. I don’t really miss Vim but if I did, it would be that aspect that I’d miss the most.

As I’ve also said before, I have significant muscle memory problems trying to use more than a single editor so we here at the Irreal bunker won’t be recreating Batsov’s experiment. And, really, muscle memory notwithstanding, I have no desire to. I’m perfectly happy with Emacs and indulge what little desire I have to tinker with editors to playing with my Emacs configuration.

There’s been a spate of posts lately about navigating among windows in Emacs and The Emacs Cat decided to jump in with a description of their own procedures. I like those procedures because they are essentially the same as mine.

Like The Emacs Cat, I use abo-abo’s ace-window to switch between windows and I don’t understand why anyone would use anything else. The idea is that when it’s invoked, ace-window will label each window with a number and you can then switch to any of the windows by typing requisite number. It’s easy and fast and after several years I haven’t found anything better.

Unlike The Cat, I just bind ace-window to Ctrl+x o. Most of the time it acts exactly like other-window because I typically have two windows open and in that case, ace-winodw simply gives focus to the other window. On those occasions when I have more than two windows open, moving to the correct window is only one additional keystroke. At one time, I also bound F8 to ace-window so I could switch windows even faster but I found I never used it.

I also use

:config (custom-set-faces
     '(aw-leading-char-face
       ((t (:inherit ace-jump-face-foreground :height 3.0)))))

in my use-package definition for ace-window so that the numbers on the windows are bigger.

Take it from The Emacs Cat and me. You really should be using ace-window to handle window navigation. It’s the best there is.

After the official release of Journelly 1.0, Álvaro Ramírez has not been sitting on his laurels. He has a long list of feature requests from his beta testers and new users and has already released Journelly 1.1 that implements many of them. You can check his announcement for the full list but they’re mostly quality of life enhancements. For example, there’s now a hashtag picker that comes up when you push the # button. He’s also added support for 10 additional languages. There’s more—take a look at his post for the details.

One interesting aspect of his announcement is that he writes about a post from Ellane telling of her experience with Journelly. She makes two very interesting points. The first is that if you sync your Journelly files to the iCloud, you can control click on the directory to keep it always downloaded. That means you always have access to it even if you are offline.

Her second point is more important. I, and many others commenting on Journelly, have stressed that one of its strengths is its integration with Org mode. Ellane says that even if you don’t know what Org is, Journelly is an extraordinarily useful app and well worth having. I made the same point while commenting on someone else’s post but haven’t stressed it enough. My use of Journelly as a memo book would work just as well even if I weren’t an Org/Emacs user. Of course, the fact that I am an Org user makes it even better.

Let me say again that I really like this app. I’ve been using it all day, every day and its ease of use and flexibility have improved my note taking. The other day I was on a web page that I wanted to save to Journelly. I was about to capture the URL and paste it into Journelly when I noticed that Journelly was in the share menu. I just clicked on it and the entry was automatically stored into Journelly for me. What could be easier? And did I mention that I can read and edit the file in Emacs?

Update [2025-05-20 Tue 19:35]: Ramírez reminds me that when you use the share button to add a web page to Journelly, you can highlight text on the web page and that will be added to the Journelly entry along with the page’s URL.

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.