Irreal

Recently I’ve written about Wilfred Hughes’ ht library for dealing with hash tables and Nic Ferrier’s kv library for dealing with alists and plists. Nicolas Petton commented that there is also the map library, which is built into Emacs as of version 25.2.

What makes Petton’s map library unique is that the functions will operate on alists, hash tables, or arrays so you don’t need to worry about separate functions for each data type. The functions do the expected things such as getting and putting values, mapping over key/value pairs, filtering, and so on.

Unfortunately, there doesn’t appear to be any documentation but it’s easy to look at the source to see what functions are available. The DOC strings do a good job of explaining what each function does.

If you have code that uses two or more of the supported data types, you should consider the map library. It provides a consistent set of functions that operate on them all. In particular, it makes it easy to change the data type of a variable because most of the code to manipulate it will be the same. As with the ht and kv libraries, the names of the functions and the ordering of the arguments are consistent and intuitive. That makes it easy to remember them.

The other day I wrote about Wilfred Hughes’ hash table library. In the comments, Noonian Atall remarked that Nic Ferrier also has a key/value library (kv) that’s worth taking a looking at.

Whereas Hughes’ ht library is primarily concerned with hash tables, Ferrier’s kv library deals primarily with alists, although it does provide functions for converting between alists and hash tables. As with the ht library, kv provides some naming consistency and saves writing simple conversion and access functions. If you work a lot with alists, you should take a look at this library and see if it can save you some time and work.

Today I learned something new. Or, rather, I got hit in the head with a cluebat. Peter Hwang asked how he could mark the word at point. Manuel Uberti answered that he usually uses Ctrl+Meta+SPC, which I always think of as marking the s-expression at point. Of course, that’s where the cluebat comes in because, duh, an atom is an s-expression too.

On most keyboards, it’s easier to type Ctrl+Meta+SPC that it is to type Meta+@. At least it is for me. The nice thing is you can mark subsequent words by repeating the Ctrl+Meta+SPC.

On the other hand, both methods mark from point to the end of the word so if point is in the middle of the word, you may not get what you want. You can mark the word that the point is in with er/expand-region, Magnar Sveen’s excellent semantic marking utility. The problem with er/expand-region is that it’s usually hard to mark subsequent words because it will look for the smallest enclosing semantic unit, which is probably not the next word.

So my (new) strategy is to use er/expand-region to mark the word containing the point and then Ctrl+Meta+SPC to mark subsequent words if I need to. That means I have to switch from Ctrl+=, my binding for er/expand-region, to Ctrl+Meta+SPC, but that doesn’t seem as awkward as the other methods I’ve tried.

If you’re an Ivy user—and you should be—you’ve probably noticed that sometimes the Ivy prompt will have an initial “^” so that the search will be anchored at the beginning of line. This happens depending on the command that called the ivy-read routine. If Ivy guesses wrong, you can always remove the “^” or add one.

Sometimes, though, it always guesses wrong for your particular work flow. I’ve just learned from this Emacs subreddit question that you can, to an extent, control when the “^” is appended to the prompt. Actually, you can specify any string to prepend.

The decision as to what to append is controlled by the ivy-initial-inputs-alist. Again, you can easily correct the default action at the time of the call so unless you have a situation where Ivy is always guessing wrong, it’s probably not worth changing the default value of ivy-initial-inputs-alist.