Irreal

Matus Goljer (Fuco1) has a really meaty post on one of the dark corners in Emacs. By dark corner I mean little understood and complicated. Fuco1 doesn’t think very much of the font lock logic, depending, as it does, on regular expressions¹. Never-the-less, he admits, it does work very well in practice. Fuco1 had a use case that he thought would serve as an example of a problem that the existing font lock logic couldn’t handle. When he looked into it a bit more, he discovered that the mechanism is a little more flexible than is generally believed and that it could, in fact, solve his problem.

I’ll let you read Fuco1’s post for the details. If you’re like me, you’ll probably never have occasion to need the full flexibility of the font lock mechanism but the details of his solution are fascinating anyway. It’s not documented very well so Fuco1 had to tease out the details by reading the code. Even the commentary in font-lock.el, which I read using the wonderful finder-commentary, doesn’t tell the whole story.

My takeaway from all this is that Emacs has some (more or less) hidden capabilities that the average user won’t ever stumble on and that sometimes you have to get your hands dirty and read the code to find out what’s going on. It’s yet another reason to spend a little time learning to read Elisp.

I’ve recently blogged about Emacs solutions to handling email. As most of you know by now, I’ve settled on mu/mu4e and have been extraordinarily happy with it. Still, not everyone has the same workflow or likes the same things. Andy C over at yakshaving.co.uk has another solution leveraging Gnus.

He was using mu4e and elfeed like but didn’t like that they each had their own UI that required him to learn different key sequences to do his work. He decided to settle on Gnus for email, RSS, and mailing lists. There were a few problems to get things working well and you should read his post to see how he solved them.

For me, the big advantage of mu/mu4e is the instantaneous search facility. I no longer worry about sorting messages into special folders; I just dump everything into a single folder and use the search function to find what I need. Andy C has pretty much the same workflow—although he stores emails by year—and had to install workarounds to get decent search with Gnus.

Oddly, even though I have often complained about using more than one editor because of muscle memory problems associated with different key sequences, I have no problem keeping the key sequences between mu4e and elfeed, for instance, separate. Even if I did, it’s trivial to rebind them to be the same so I don’t see the advantage to switching to Gnus because of it.

Of course, many people, including our fearless leader John Wiegley, swear by Gnus. It serves their workflows and makes them productive. But that’s a little different from trying to make Gnus look like some other solution. Regardless, Emacs, as I often say, allows us to have it our own way. If you like Gnus but want a decent way to search your emails, perhaps Andy C’s post can help you achieve it. If you don’t have special needs, like Wiegley does, mu4e provides an excellent solution. Emacs can provide whatever works for you.

Alexandro de Oliveira has a problem that I’ve also experienced. He wants to know how he can read a complete description of a package such as that given on its Elpa page. He asked on Stack Exchange and gave as an example the documentation for undo-tree. I’ve had that exact problem. I’m always forgetting some of the undo-tree keystrokes and that means I have to bring up the source to read the commentary at the front of the source file.

It turns out that there’s a much better way: as suggested by wasamasa, simply use finder-commentary to extract the commentary from the source file. That function is part of the finder package written by Eric Raymond back in 1992 so it’s been around for a long time but this is the first time I’ve heard about it.

If you’re writing a package, this tip should encourage you to spend some time on the commentary section. It can really be useful to your users, especially if the package’s UI is the least bit complicated. As usual, I’m always learning something new about Emacs.