Irreal

I didn’t even know there were plans for an Emacs 26.3 but there are and the first release candidate is available. If you don’t want to live on the edge enough to be running the development version of Emacs 27.1, perhaps you’d enjoy the safer route of helping to test Emacs 26.3 by trying out the release candidate.

Protesilaos Stavrou has posted a very nice video on using editable occur to solve a real life editing problem. The basic strategy is to use occur to locate all the occurrences of the problem to be fixed, type e in the occur buffer to make it editable, and then use a keyboard macro or other means of your choice to make your changes. The changes are, of course, reflected in the original buffer and are written to disk when you exit the edit mode of occur.

This is very reminiscent of abo-abo’s refactoring workflow that I wrote about back in 2015. The idea is basically the same: use some sort of grep-like operation to get all the relevant lines in a buffer, make the buffer editable, make your changes, and write those changes back to the file(s) they occurred in.

If you like this sort of thing, abo-abo has a video demonstrating a workflow similar to Stavrou’s. It is, I think, hard to find better examples of the awesomeness of Emacs’ editing capabilities than these videos by Stavrou and abo-abo.

As a final note, I was pleased to discover that you can make an occur buffer editable simply by pressing e. I always did it by toggling the read-only state with Ctrl+x Ctrl+q. I’m not sure why I didn’t know about using e since I use the facility all the time but then I’m always learning something new about Emacs that you’d think I would already know.

Saturday, I wrote about Slava Akhmechet’s The Nature of Lisp, which discussed why Lisp is such a powerful language. A day or two afterwards, I serendipitously came across a tweet pointing to Steve Yegge’s old post, The Emacs Problem. That’s a really great post and if you haven’t read it yet, you definitely should. I’ve written about it a number of times including here and the series of posts starting with this one on treating data as code. Those last posts are among my favorites in the Irreal canon. Among other things they demonstrate the power of Emacs viewed as a kind of Lisp Machine.

Yegge’s and Akhmechet’s posts are complementary. They both start by considering XML as the solution for a problem and show that

1. Expressing the data structure as an S-expression makes it less verbose and much easier to read.
2. Once expressed as an S-expression, the data can be thought of as code and made to perform useful transformations on itself.

A lot of this boils down to Lisp being really good at text manipulation or, as Yegge puts it, the only language that’s really good at it—at least for non-trivial data. Yegge’s post starts by considering the notion that Lisp is terrible for text manipulation, that Emacs proves that, and that Emacs should be rewritten in some other language such as Ruby. By the end of his post, that notion is a smoldering heap of ashes.

Akhmechet, on the other hand, doesn’t consider Emacs at all. He just lays out the case that Lisp, although hard to grasp at first, is a very powerful language and very often the right solution. Emacs is, I submit, proof of that assertion.

I’ve written before about directory local variables (1, 2) and how they can be useful for setting variables or actions with a directory-wide scope. Over at the Emacs reddit, fearbedragons has a nice tip that leverages them to slightly reduce his workflow friction.

Fearbedragons has a project in which he needs to make a lot of small compiles as he goes about his testing. To help with that he set up a small .dir-locals.el file in the project directory that automatically compiles the whole directory when any file is saved. You may or may not want to do that for your own projects but the same idea works for any action that you want to take on a file event. As fearbedragons says, “You don’t always need it, but it’s sure handy when you do.”

This post is already longer than fearbedragons’ whole tip so stop reading here and go on over to reddit to take a look at the tip. It’s also worthwhile to follow his link to the dir-locals documentation to see how things work. The syntax can be a bit confusing but, as usual, Emacs can help you out by writing the entries for you. Just call add-dir-local-variable and follow the prompts. This is a useful facility that I, at least, do not use nearly enough.

I always update my Emacs packages on Sunday. I’ve found that upgrading once a week is more than enough and helps limit the ever-increasing entropy here at Irreal. This past Sunday, I noticed that there was a new Org-mode in ELPA. Because Org is central to my workflow, I’d taken to using the GNU ELPA version rather than the more up to date but maybe not quite stable version from the Org repository.

When I tried to update the packages, the update aborted because it couldn’t load the new Org-mode. It said there had been a bad request. I took that to mean that the tar file was missing for some reason or another and put off upgrading until Monday. But on Monday the same thing happened. Finally, on Tuesday I saw a tweet pointing to a reddit discussion of the problem.

It turns out that there is a problem downloading from the GNU archive that’s related to TLS. Happily, the answer is simple: just add

(setq gnutls-algorithm-priority "NORMAL:-VERS-TLS1.3")

to your init.el file.

Oddly, it turned out that I already had that line but it was commented out and replaced by a line that set gnutls-algorithm-priority to nil. I vaguely remember changing it to nil some months ago because of a security problem with gnutls. Presumably that’s been fixed now. I switched the commenting on the two lines, evaluated the uncommented one, and when I invoked the update function everything worked fine.

If you’re getting weird errors when you download from the GNU repository, try adding the above line to your file. It worked well for me.