Irreal

I was reading this post on some Ivy hacks and it reminded me of another post that I’ve been meaning to comment on. Over at the CollBox blog, Cameron Desautels writes about the Emacs concept of future history.

The idea is that Ctrl+m used to move to the next minibuffer history entry is overloaded to move beyond the current entry to a future entry. What it does is bring up any DEFAULT value(s) specified in the call to read-from-minibuffer or read-string.

That’s handy but what I found most interesting was the fact that Desautels started the post with: you can use the same mechanism to edit a default value offered by a prompt. Take a look at Desautels’ post for the details and some examples.

Rakhim Davletkaliyev, whose EmacsCast podcast I’ve written about many times, has published a video on his Emacs configuration and workflow. As you know by now, I always enjoy seeing how others use Emacs and most often learn something new or get a good idea for my own workflow.

Davletkaliyev’s workflow and the Emacs packages he uses are much like mine. Well, except for the keybindings. I’m almost always content to use the default keybindings but Davletkaliyev has aimed to make his bindings as much like that of the other software he uses as possible. Since he’s on a Mac, that means using the ⌘ Cmd key in many of his commands. For instance, he uses ⌘ Cmd+o instead of Ctrl+x o to switch to the next window.

My first thought was that I should be doing something like that too because it would decrease the number of different bindings for similar operations among the applications I use. Then I realized that

1. Almost everything I do except for the browser is done in Emacs.
2. For the browser and any other extra-Emacs application I may need, I have Emacs keybindings configured for all the mac commands.

So in a sense, I solved the problem in exactly the opposite way: rather than adapt the Emacs keybindings to be like native app bindings, I configured the native apps to have Emacs keybindings. Either way, it reduces the cognitive load when switching applications.

Davletkaliyev’s video is about 16 and a half minutes but well worth watching. If you want to see exactly how he has things configured, there’s a link to his configuration.

If you’re a mu/mu4e user, there’s good news. Version 1.2 has been released. It’s mainly a bug release but there are a handful of new features, which you can read about here. I’ve been using it for the last few days without difficulty.

Of course, since I’m running on a Mac, upgrading was a bit complicated. The new version of mu requires an updated Xapian that, in turn, had some updated requirements of its own. Rather than go through the pain of building it by hand, I took the easy way out and installed it with Homebrew. Homebrew installs things in its own special place so the mu build was still finding the old version in /usr/local/bin. I ran a make uninstall on that and then added a link in /usr/local/bin to Homebrew’s copy of xapian-config. I also had the fix the path to bash in the install script but that may be a local artifact on my machine.

Once all that was done, everything worked fine and I’m enjoying my new mail client. If you’d like to read and write your email from inside Emacs, mu/mu4e offers an excellent solution. I’ve been using it for a couple of years and love it.

In the last week, I’ve installed the new mu/mu4e and the new Emacs. Life is good.

It’s official. Emacs version 26.2 is out and available at the usual places. I compiled and installed it on my Macs without any problems using the usual spell:

configure --with-ns CFLAGS="-g3 -O2 -I /usr/local/include/libxml2"
make
make install
make install-info
sudo mv  nextstep/Emacs.app/ /Applications/

This post is being written with it and so far (after a day) I haven’t seen any problems. If you’re uncomfortable living on the edge and have been waiting for the official release, it’s here. Thanks to John, Eli, Nico, and the others for all their hard work.

Maybe the Emacs developers knew what they were talking about after all. A couple of years I discovered that you can control the sequence of positions to which recenter-top-bottom will move the current line. As I wrote at the time, abo-abo recommended changing the default sequence from middle \(\to\) top \(\to\) bottom to top \(\to\) middle \(\to\) bottom. As abo abo said, if you believe in gravity that sequence is more logical and is also more convenient. That made perfect sense to me and I changed it in my config.

Lately, I’ve noticed that I almost always end up using Ctrl+l twice because—unless I’m looking at a function definition—I need to see what comes before the target line too. If I am looking at a function definition, Ctrl+Meta+l does just what I want.

Therefore, today I bowed to the developers’ wisdom and changed the recentering order back to the default.