Irreal

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.

Robert Johnson has a useful post on Everyday editor extensions in Emacs. Most Emacs n00bs and even many seasoned Emacers assume Elisp is too obscure and hard for “normal” users so they avoid it. Of course, that’s not true at all. As Johnson shows, it’s pretty easy to get started making simple extensions without having to know much about Elisp.

He demonstrates this by making a very simple Emacs function that simply opens the browser at some fixed site—github/spacemacs in his case. From there, he adds the ability to enter parameters, first by having the user enter them, then by using thing-at-point, and finally by using a prompt if thing-at-point fails.

At that point Johnson has a useful function that anyone could customize for their own workflow. Next he considers calling a shell command rather than the browser and having the results put in an Emacs buffer. That’s great, of course, because you can stay in Emacs and don’t have to switch out to the browser.

All of this uses only a minuscule fraction of the Elisp language, of course, but still manages to produce useful extensions. The important, unstated, advantage, though, is that once you get comfortable with this tiny portion of Elisp, it’s much easier to move on to the rest of the language. Developing even a minimal working knowledge of Elisp will open up a whole new dimension of Emacs to you.

Ashton Wiersdorf has a very interesting post on refactoring in Emacs. His problem is a simple one: we wants to replace all occurrences of set_XXX_config! (where XXX varies) to config_XXX! for all files in a directory. He uses several packages to support this but the only one really necessary is wgrep, which make a search results buffer writable and saves the changes to it back to the original files.

His strategy is to

1. grep for the appropriate regex,
2. put the search results in a separate buffer
3. make the buffer writable with wgrep
4. use something like replace-regexp to change the identifiers
5. save the results back to the original files

If you’ve been around Irreal for a while, this probably seems familiar. In abo-abo’s original post, he used rgrep so he didn’t need to worry about getting the results into another buffer but my process uses counsel-rg so I need a Ctrl+c Ctrl+o to move the results from the minibuffer to a separate buffer. After that, things are mostly the same. The nice thing is that Ivy handles all this for me and I don’t need any other packages besides wgrep.

This is a great way to refactor. The process, Wiersdorf says, is better than trying to do it from within an IDE using some sort of language server because it finds and changes all occurrences of the target identifiers including those in, say, documentation files that a language server is not going to find. It’s my favorite way of solving this problem. After you try it, it will probably become yours too.