Irreal

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.

The other day I wrote about installing elfeed-webkit to render my RSS feed as proper HTML. I was pretty impressed with it when I first tried it and now I’m even more of a fan. Before elfeed-webkit, I spent a lot of time switching between Elfeed and Safari so that I could read interesting posts that came up in the feed. It doesn’t seem like it would take that much time but since the change, my RSS workflow seems faster and easier.

A secondary advantage is that Emacs has more functionality now that I have XWidgets enabled. At first I wondered if I could get eww to do a better job rendering sites by using Webkit. That turned out to be a bust but I did discover xwidget-webkit-broswse-url that will render a site in decent HTML but it’s not a proper Browser so it’s pretty much restricted to viewing a specific URL. You can follow links and control videos but there are no bookmarks, content filtering, or other Browser amenities. Still, it does help keep me in Emacs and a lot of times I just want to visit a page from Emacs and it works perfectly for that.

In my original post, I noted a couple of problems. The first was the possibility of being inundated with ads because of the lack of content filtering. That’s basically a nonissue for the sites I read although occasionally a feed item will send me off to a “commercial” site that does have a lot of intrusive pop-up adds but it doesn’t happen often.

The second problem was that I couldn’t get t to toggle elfeed-webkit on and off. I thought maybe something else was grabbing the t binding to I changed it to w but that didn’t work either. I solved that by binding a global key to toggle elfeed-webkit and that worked fine (but see below).

Finally, I recently upgraded my email client mu/mu4e and a helper function I wrote to display the post in eww stopped working. While investigating that, I discovered that mu4e will display an email with webkit, which is what I really want so I’m now using that instead of eww.

While investigating the email issue I discovered that the XWidget library does indeed capture the t key as well as the w key. The t doesn’t appear to do anything useful as its definition

(define-key map "t" (lambda () (interactive) (message "o"))) ;FIXME: ?!?

shows. I don’t know how it was working for Grabo; perhaps he’s using the Emacs 29 pretest and it has removed the useless binding. In any event, I simple changed my toggle key to x and now it works perfectly.

That leaves only one small problem. One of the sites I follow, Daring Fireball, has the unusual property that its RSS URL is not the site itself but the site it’s linking to. That means that I miss the Daring Fireball commentary and go straight to the linked site. I’m considering adding code to implement a tag that inhibits rather than enables elfeed-webkit. In the meantime, I’m simply toggling elfeed-webkit off when I get to a Daring Fireball post.

All in all, I’m really happy with elfeed-webkit and recommend it wholeheartedly.