Irreal

If you’ve been around Irreal for a while, you know that I’m a hug fan of abo-abo’s Swiper/Ivy/Counsel package. Its minibuffer completion system means that if I can get anywhere near the name of a command I’m trying to run or a file I’m trying to open, Ivy will find it, usually with just a couple of keystrokes. Even for complicated names, its builtin easy regular expression engine can easily filter a huge list of candidates to just a few close matches.

It turns out that I’m not the only fan. Martin Fowler is a well known software engineer and author who is also a long time Emacs user. Among his favorite Emacs tools is the same Swiper/Ivy/Counsel package much beloved at Irreal.

He has a post describing his Ivy use and how it makes his work much easier. He does a good job of describing the regular expression engine that will translate a space into .* so that foo bar will match any (sub)string beginning will foo and ending with bar. Two spaces are mapped to a space so it’s really easy to write a regular expression that usually does the job without resorting to the full Kleene notation.

Another nice (optional) feature of Ivy is that it can ignore order so that foo bar will match both foo comes before bar and bar comes after foo. You can turn that on for a single instance or configure Ivy to always use it. Check out the post for the details if you’re interested.

If you want to see how Ivy can meet your completion needs, take a look at Fowler’s post.

Update [2024-02-07 Wed 15:43]: Consult → Counsel

Ruslan Bekenev has an interesting post that discusses which-function-mode. I was vaguely familiar with it before I read Bekenev’s post but never thought much about it. Bekenev, however, makes a good case for it. His use case is that he has long functions and deep Org trees and it’s nice to be able to see at a glance where he is.

Wait. What? Org trees? What do they have to do with functions? Probably nothing but the thing is that when which-function-mode is on, it does an excellent job of telling you were you are regardless of what object it’s dealing with. If you’re in an Org tree, it will tell you what subheading you’re in. If you’re in a code buffer it does a similarly good job. I tried it out in my init.el and besides functions, it identified setq, devar, define-key, use=package, and, doubtless, many other objects.

Bekenev says that it worked on most of the files he tried except for files containing HTML. Still, it seems pretty complete.

If you’re a good doobie and keep your functions short it may not do much for you and in any event, if you’re working in a function you’d better know what function it is. On the other hand, it’s easy to imagine searching for a variable and landing in the middle of a function and having no idea what function it is. It may, ironically, be more useful in Org files. Of course, that’s just my take and you may have a very different opinion.

In any event, which-function-mode is a handy thing to know about. Bekenev’s post is short and well worth a minute or two of your time. Check it out.

Update [2024-02-04 Sun]: Fixed link.

Emacs Elements has a very short video on a relatively unknown but extraordinarily useful command: iedit. It does basically the same job as multiple cursors but is builtin and a bit simpler. It’s less powerful than multiple cursors but is usually more than powerful enough for the job at hand. I use it all the time, usually in preference to commands like query-replace and its siblings.

The video is less than two minutes long so it doesn’t cover many of the nuances involved with iedit. The most important such nuance is what text is selected for editing. If you just place the cursor on some text, the selected text is basically what’s returned by thing-at-point. I often find that that is not what I want so I highlight the word (or extended text) that I’m interested in instead. Then, that text is selected as if by a substring match. On the other hand, that may not always do the right thing either so you should be familiar with both methods. You can also edit the regular expression by hand to get exactly what you want.

Another obscure but useful nuance is restricting the range of selection to the current function. You do that by by specifying a prefix of 0 to the command. There’s a fairly long description of how the command works in its document string so ts worthwhile calling Help for iedit to get the full story.

As I said, the video is very short—only 1 minute, 55 seconds—so it’s easy to fit in. Take a look at the video to get the general idea but you should definitely read the Doc entry too.

Protesilaos Stavrou (Prot) has a great video on nesting key maps. A nested key map is just what it sounds like: a key map inside another key map. What that means practically is that one key shortcut will lead to another key map of additional choices.

In theory it works just as you think it should but there are some nuances and it’s nice to have the whole thing explained in one place. Prot’s video uses keymap-set and defvar-keymap, which assume you’re using Emacs 29 or later but even if you aren’t the process is the same except that you have to use the older commands such as define-key and make-sparse-keymap.

You can watch the video to see how to set up nested key-maps but, as I say, it works just like you think it would. One of the non obvious things that the video explains is how to deal with describing the key maps in which-key. To see why this matters, type Ctrl+x and wait until which-key pops up. You’ll see a lot of entries that say +prefix but there’s no indication of what the resulting key map does. Prot shows how to configure which-key to give the key map a meaningful name. That alone is worth watching the video for.

The video is 23 minutes, 17 seconds long so plan accordingly but you really should find some time to watch this video. If you hate watching videos, at least take a look at the sample code at the link. It’s a nice précis of how to set up nested key maps and configure which-key.

Recently, someone posted a link to Artur Malabarba’s old blog. Sadly, Malabarba no longer posts to it but it still has a lot of good and relevant information. The link was to a Malabarba post about directory local variables.

The idea is that you can place various variables controlling Emacs in a file in a directory and those variables will apply only to other files in that directory (and its subdirectories). It’s ideal, for example, if you have a project directory and would like to apply some Emacs customizations to the project’s files. You can specify that variables should apply only to file having a specific major mode or to all files.

The file format is a tiny bit fussy but fortunately you can simply call add-dir-local-variable and it will prompt you for the necessary information and write it to the local variables file, creating it if necessary.

I really like the idea but it never seems to work for me. That’s mainly because almost all the customizations I want to make involve running some code—invoking a minor mode, for example. File local variables support this (see Malabarba’s post or the documentation for the details) but every time I try to use it I get error messages about exceeding maximum evaluation depth. I wrote about this back in October.

Malabarba’s post is short and well worth a read if you’re not familiar with directory local variables or have mostly forgotten the details.