Irreal

It’s odd how discovering some small Emacs feature can completely change your workflow. Yesterday, I wrote about counsel-git-grep and how it made searching entire repositories easy. Almost without me being aware of it, it changed my blogging workflow and allowed me to bring one more task into Emacs.

When writing a post, I often want to refer to one or more older posts that are related in some way. My normal way of doing that was to use the search feature of Irreal to locate the posts and then leave them up in my browser so I could review them and then link to them from within Emacs. That meant I had to leave Emacs to interact with the blog itself and, of course, it meant I had to be on-line.

That procedure’s a bit silly because I write my posts in Org mode and have the original source immediately available to me in Emacs. Still, searching the source wasn’t really that convenient and I’d end up with a lot of buffers open I didn’t need. Counsel-git-grep changed that. I do the search and can see the results in the minibuffer. I can open the one(s) I want easily, review the contents, and then link to them from within my current post.

I use two methods for linking to the old posts. The first makes use of irreal-link, shown below, to add a link without bothering to open the old post in Irreal. When org2blog publishes a new blog post, one of the things it does is put the page ID into the source buffer. That makes it easy to link to the post by referring to its ID (see the irreal-link code). Notice that there’s no browser interaction involved with this process at all.

Sometimes, it’s convenient to have the actual page up in the browser. For those occasions, I use irreal-by-id, which opens the page in the browser from within Emacs. I send the results to Safari but I could just as easily open it in EWW. Since it is open in Safari, I can add the link in the way I described in the “link to them from with Emacs” link above.

Here’s the code for irreal-link and irreal-by-id. As you can see they are trivial but make linking to the old post easy and convenient.

(defun irreal-link (id label)
  "Make a link to an Irreal post given its ID number and a LABEL."
  (interactive "sID: \nsLabel: ")
  (insert (concat "[[http://irreal.org/blog/?p=" id "][" label "]]")))

(defun irreal-by-id (id)
  "Open an Irreal page by its page ID."
  (interactive "sID: ")
  (browse-url (concat "http://irreal.org/blog/?p=" id)))

After rewatching abo-abo’s refactoring video I decided check out his other videos. I’ve seen most of them, of course, but mostly forgotten the details. One video, counsel git grep demo, is really informative and worth your time.

If you have the Ivy/Counsel/Swiper suite installed, you already have counsel-git-grep. It’s a really handy way of grepping through a git repository. That may sound a bit limited but it’s not. What it does is grep through all the files in the current git repository where “current git repository” means the repository that has a .git directory in the current directory hierarchy. It works by calling git grep so in a sense it’s nothing new but it’s really handy to be able to invoke from within Emacs without having to shell out. All the results are put in the minibuffer in the usual Ivy way so it’s easy to find the right match or to put the results in a separate buffer by calling ivy-occur and deal with the matches one-by-one or even en masse as described in the refactoring video.

After watching the video, I added bindings for counsel-git-grep to my configuration so that I can call it easily. The video is only 4 minutes so you can watch it twice while the coffee’s brewing.

I was trolling through some of abo-abo’s old posts over at (or emacs and came upon this gem concerning the order of positions for recenter-top-bottom. I use this command all the time; it’s really handy when a search result leaves the target at the bottom of the screen. A simple Ctrl+l and the line is repositioned to the middle of the screen. Another Ctrl+l and it’s positioned at the top. A third invocation returns it to the bottom.

As abo-abo says, this is a bit counter intuitive and not as handy as you’d like it to be. In the common case of searching for a function, you’d like to position it at the top so as much of the function as possible is visible. Of course you can do that by pressing Ctrl+l twice but it would make more sense for it to start at the top.

Being Emacs, the behavior is, of course, completely configurable. You can set the order to be anything you like. If, as abo-abo says, you believe in gravity and want as much of the result showing as possible, you can set the order to be top-middle-bottom with

(setq recenter-positions '(top middle bottom))

I like that better but others may disagree. The beauty of Emacs, as always, is that you can have it your way.

One annoying feature of many modern development systems and sometimes even single programs is that they hide files or directories in a long, nested series of otherwise empty directories. That is, each directory other than the last contains only a single entry. GitHub has a nice solution for this: they collapse the entire path of otherwise empty directories into a single path. That makes it easy to get to the target without navigating through a bunch of essentially unused directories.

Fuco1, who has little tolerance for such infelicities, has introduced dired-collapse-mode to bring the same functionality to dired. Follow the link to Fuco1’s post to see an example of the mode in action. It’s on Melpa so it’s easy to install and try out. If you have a lot of these nested directories ending in a single target, you should give dired-collapse-mode a try. You having nothing to lose but your frustration.

If you’ve ever wondered which packages are slowing down your Emacs load time, Matthias Bloggt has a quick and easy way of finding out. The TL:DR is that he surrounds each package load (really, each section of his config) with some unique comment strings. When he wants to measure his load times, he does a query-replace-regexp to add code that captures the name of the section and the internal running time.

Afterwards, he runs an Org Babel file that post processes the data and produces a graph. It’s all very simple and doesn’t require a lot of setup or a fancy framework—other than Org mode, of course.

Also be sure to see the comments where Sacha Chua suggests an alternative method using use-package. If you’re already using use-package, and you should be, that may be an easier way.

Last year I wrote about abo-abo’s screencast demonstrating a bit of his refactoring workflow. I just ran across it again and it’s so great I want to mention it once more in case some of you haven’t seen it.

The video shows how he does a small refactoring of some code in his Avy library. The basic plan is

1. Use swiper to locate every instance of the code to be changed
2. Call ivy-occur to save the swiper results to a separate buffer
3. Switch to the occur buffer
4. Start a keyboard macro
5. Select the first item in the occur buffer
6. Perform the refactoring of the first match (we’re now in the code buffer)
7. Switch back to the occur buffer, move to the next item, and end the macro
8. Run the macro on the rest of the items.

Notice how he is switching buffers while recording the macro. This is a much more efficient method than, say,

1. Search for the first match
2. Perform the refactoring while recording the macro
3. End the macro and save it
4. Search for the next match
5. Run the saved macro if not done
6. Goto 4

Actually, abo-abo also collects some information along the way that he uses to set up defaults. He puts this in a third buffer so his macro is actually dealing with three buffers. This is a brilliant use of keyboard macros and a tour de force in refactoring technique. It’s worth watching for the entertainment value alone. It’s only 10 minutes so there’s no excuse for missing out.

This is the second of my two-part post on packages that I find especially useful in my day to day work. I’ve discussed all these packages before but it’s worthwhile bringing them all together as suggestions that others might want to try out.

I used guide-key for some time until Kaushal Modi recommended I try out which-key as a replacement. This package is the ultimate in ease-of-use. Just install it and forget it. If you pause in the middle of a key sequence, which-key will pop up a buffer of the possible completions and what they do. You don’t have to specify what sequences you want it to work for; just pause and it will tell you what it knows. You can adjust things like the font and colors and the amount of time you have to pause but I did none of that and it works perfectly for me. Mostly, it stays out of the way but when I want to call a seldom-used command and can’t remember the whole sequence, it pops up a buffer that displays the possible completions.

I’ve written about mu4e so many times that I’ll just give the results of a blog search for reference. If, like me, you’re the type who wants to bring as many of your tasks as possible into Emacs or if you just want to have the convenience of Emacs editing for writing your emails, mu/mu4e is an outstanding solution. One of the things I love the most is that I no longer worry about storing away saved emails in a particular folder. There’s only one folder for that and I locate old emails in it with the extremely powerful search provided by mu.

There are other popular solutions—the notmuch suite seems to be a favorite—that do much the same but I’ve settled on mu4e and have been very happy. It’s still under active development so I don’t see myself changing systems. The only downside is that configuring mbsync can be tricky—especially for macOS—but I provide detailed instructions for that in one of those blog posts I mentioned above.

Once I got mu4e installed and working, I brought the last remaining assimilable task into Emacs: my RSS reader. For that, I used the wonderful elfeed package. It’s easy to use, and puts all its results in a database that is easy to search. For an excellent introduction to the post, see Mike Zamansky’s 3 videos on Elfeed, especially the first.

As part of getting mu4e working, I needed an easy and secure way of providing the passwords for my SMTP servers. The way to do that is with authinfo and the associated ~/.authinfo file. I just put the services and associated passwords in the .authinfo file and encrypt it. When Emacs starts up (about once every week or two for me) it will ask me for the password to decrypt .authinfo and will just cache the results. The documentation says that there’s some time limit before the cache expires, but for me, at least, I’ve never had it ask me for the .authinfo password except at Emacs startup.

You can put any of your passwords in the .authinfo file and retrieve them with auth-source-user-and-password. I do that, for instance, for my WordPress password for Irreal. It’s very handy.

Finally, there’s winner-mode. I’ve been using it for a long time and don’t know why I didn’t mention it in my first “Oldies but Goodies” post. It’s built into Emacs so all you have to do is enable it with

(winner-mode 1)

Thereafter, you can recover a previous window configuration by simply typing Ctrl+c ← repeatedly until you’re back to the desired configuration. It’s just perfect for those times when you have a complicated window configuration showing and then need to, say, call help or some other function that changes the window configuration. With winner-mode you can make your call and then reestablish the old configuration easily. Actually, you can scroll the window configurations in either direction by using Ctrl+c → to move to newer configurations but I never do that.

I hope that you’ll find some of these packages useful and start using them yourself. They make my workflow much more frictionless and make my editing easier and more fun.