Irreal

Zachary Kanfer has a useful post for those of you who want to reduce to a bare minimum the amount of code you have to write to configure Emacs. Kanfer was bothered by all the boilerplate you have to enter to make a keymap so he decided to write a couple of functions that simplified the process. While getting ready to publish his code, he discovered define-keymap. It is, strictly speaking, an Emacs 29 functionality but Emacs 28 has the compat-29.el module that backports define-keymap and other functionality to older Emacs versions. The nice thing about it is that it removes all the complexity and boiler plate involved in making a key map. Basically all you do is list the bindings (as text strings) and the corresponding functions. It could hardly be easier.

Personally, I’ve never found the old way of defining keymaps that onerous—although it can be hard to remember the exact spell if you aren’t doing it all the time—so I’m not going to jump into using define-keymap but I could see myself using it if I needed a quick keymap and didn’t want to look up the make-keymap incantation.

If you’re on Emacs 29, Emacs 28, or possibly older versions, invoke describe-function on define-keymap to see all the details. If you’re into simplifying your init.el, take a look at Kanfer’s post to see one way of doing that.

A useful but underused Emacs facility is narrowing. The idea is that you can limit the visibility of a buffer’s text to a region, function, or an Org mode subtree. The rest of the buffer is still there but you can’t see or access it. The operations are pretty simple but still seem hard to remember for many people.

Over at Emacs Elements Channel there’s a new video on narrowing and how to use it. As I said, it’s really pretty simple despite the problem some folks have with remembering the keystrokes. The biggest problem is widening or undoing a narrowing. I don’t understand these problems even though I had them myself.

Artur Malabarba to the rescue. In his now, sadly, abandoned site, Endless Parentheses, he presents the narrow-or-widen-dwim function that makes using narrowing trivial. If you call it and the narrowing is already in effect, it widens the narrowed text. Otherwise it narrows to the proper text given the context. As I say in the above post, I don’t think I’ve called any of the narrowing functions directly since I installed it. Like Malabarba, I put it in my “toggle” key map so it’s easy to remember and use.

The video is only 6 minutes, 12 seconds long so it should be easy to watch. After you do, be sure to check out Malabarba’s function. It will make using narrowing easy. I installed it 9 years ago and haven’t used anything else for narrowing since.

Protesilaos Stavrou (Prot) has a really, really excellent video on the Emacs search/replace functionality. Except for a short section at the end, it doesn’t consider external packages; it’s about the default functionality. Although Prot says the video considers only the basics and is not meant to be comprehensive, it is, in fact, a fairly complete explanation of how you can search and replace out-of-the-box with Emacs.

Prot starts, of course, with isearch. You wouldn’t think there’s that much to know other than, say, being able to search in reverse but there’s much, much more. You can, for example, move forward and backwards within the matches using Ctrl+s / Ctrl+r (with the default bindings). That’s pretty well known but did you know that you can exit the search with any motion command? That’s really handy if you want to position the cursor at, say, the beginning of the target word. Just type Meta+b to exit the search and put the cursor at the start of the word. There’s plenty more functionality including putting the results in an occur buffer so take a look at the video for the details.

Of course, you can also do regular expression searches. I generally use swiper-isearch from the Swiper/Ivy package to do my searches and one of its features that I really like is that a single space in a regex is interpreted as .*?. That covers a surprisingly large fraction of the cases that you use more complex regexes for. It turns out, that you can configure isearch-forward-regexp (and its backward sibling) to the do same thing. See the video for the magic incantation.

The search commands all have corresponding search/replace variants and Prot covers those too. Most of the extra functionality that Prot describes for searching applies to those commands too.

Finally the video considers occur and wgrep and how you can move to these from any of the search commands. There’s a lot of material so you need to watch it to see everything that’s available. The video is just short of an hour (53 minutes, 2 seconds) so you’ll need to schedule it but believe me, it’s worth your time.

After yesterday’s post I started thinking about what the real advantage of Emacs is. There are, as I’ve said many times, plenty of advantages but if you had to choose the most important one, what would it be?

My recent experience with elfeed-webkit crystallized this for me. It started with Christopher Wellons feeling that he needed a better RSS reader and that he’d like it to run in Emacs. The result of that itch was what I consider the best RSS reader in any environment: elfeed. The point here is that Wellons is just a guy with a problem but Emacs made it easy for him to solve that problem and make the result available to all of us.

But wait. There’s more. Fritz Grabo was an Elfeed user and liked it but many times he had to switch to his browser to read a post and then switch back to Elfeed. That was a pain so he started wondering if there was some way of faithfully rendering the HTML directly in Emacs. It turned out that of course there was. You can compile Emacs with XWidget support and then use Webkit to render HTML accurately directly in an Emacs buffer. Grabo used that to make elfeed-webkit and suddenly reading your RSS feed is even easier and more pleasant than it was before.

That’s the thing about Emacs: everything is available for you to extend it in any way you like, sometimes in surprising ways. Reading RSS feeds is, after all, only marginally related to text editing but as I’ve written so many times before, Emacs is much more than an editor so it has us covered.

For me, therefore, the most important advantage of Emacs is its extensibility. If it isn’t quite what you want, Emacs makes it possible to make it exactly what you want.

What do you think? Is Emacs slow or is that just another instance of Emacs hater FUD? The most frequent complaint I see about Emacs—with the possible exception of its lack of bling—is that it’s too slow.

I don’t understand that. Maybe that’s because I’m old enough to have used some genuinely slow tools but I’m pretty sure it’s just that I have more sensible standards. Sure, other editors may be faster at one task or another but I have always found the differences in speed essentially undetectable by human beings in their normal workflows. In other words, Emacs is fast enough where it counts.

Corwin Brust over at Corwin’s Emacs Blog examines this question in his blog post, The Turtle and the Snail. The title comes from a joke involving a turtle and snail that has application to the question of Emacs’ speed. I’ll let you check out the joke on Brust’s post but the TL;DR is that speed—at least if we aren’t speaking of light—depends on the observer.

Brust mentions a related complaint: “[I]t consumes too much of my time, to understand and configure, and to enhance it.” That’s just plain silly. Unless you’re one of those people who demands instant gratification and are unwilling to expend any effort to attain it, the complaint is frivolous. When I started, I printed out the cheat sheet and was using Emacs reasonably productively on the first day. To be sure, I wasn’t as fast as I was with Vim but that came fairly quickly.

As for understanding and configuring it, we all know that that’s a lifetime journey. Like every other Emacs user, I’m still learning new things about Emacs and my init.el is a lifelong project. If this idea of a lifetime commitment bothers you, perhaps Emacs is not for you.