Irreal

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.

Over at the Emacs Elements Channel there’s another useful video up. This time it’s about the Emacs Help system. The majority of experienced Emacs users will already be familiar with most of the material but if you’re a learn-as-you-go user, there may be some information new to you.

The first thing is that Ctrl+h Ctrl+h will show you a list of all the help commands. If you’re like me, you know this but always forget it when you’re trying to remember a help command. There are a lot more commands then the ones you use everyday so it’s worth your while to type Ctrl+h Ctrl+h to see what’s available.

For example, I’d completely forgotten about Ctrl+H w to discover the shortcut for a given command. My usual procedure is to bring up the documentation for the command and get the information there but I’m going to try to remember to use Ctrl+h w instead.

Another thing that I learned from the video is the difference between scrolling up and down with Space and Delete versus the <PgUp> and <PgDn> keys. I’ll let you watch the video to see what that difference is.

The video is 14 minutes 52 seconds long so it shouldn’t be too hard to find time but you may have to plan ahead.

I’ve written about Clojure’s threading macros and their implementation in Elisp before [1, 2, 3, 4, 5]. I like them but almost always use the traditional composition of functions instead. That’s probably because being a mathematician it seems natural to me. Still, the threading macros are easier to read and understand.

Most people who care about such things know about Magnar Sveen’s implementation of these macros in his Dash library. They have the advantage of using the same names, ->, ->>, etc. as clojure. Of course, you have to install Dash to use them. That’s not much of a problem because so many packages use Dash that it’s probably already installed.

But what if you don’t want the dependency? It turns out that Elisp has the most important of these macros built in and has since at least Emacs 25. The first, thread-first corresponds to -> and the second, thread-last, corresponds to ->>. They live in the sub-x.el file if you want to check out there definition.

Ruslan Bekenev has a page that explains all this and even gives a short explanation of how to use the macros. If you’re interested in the threading macros, take a look at his post.