Irreal

Charanjit Singh says he has a hard time remembering what he reads. It’s a common enough problem and Singh has settled on a common solution: he takes notes on what he reads. There are lots of ways of doing that, of course, but this being Irreal, it’s not a hard guess that his note taking workflow revolves around Emacs.

His workflow involves three components:

1. Emacs
2. Denote
3. Spookfox

Spookfox is Singh’s package for talking to Firefox.

He takes two types of notes:

Reading notes

These are notes he takes on what he reads, usually in Firefox, and

Normal note

These are notes that summarize and discuss his reading notes. They link back to the reading notes so that he can see the source.

You can get the details in his post but Singh’s workflow is pretty much like mine except that I use Org mode rather than Denote and talk to my browser (Safari) using some homegrown AppleScript and Elisp glue. It’s a great way of keeping tack of what you read, especially if you read a lot or have a hard time remembering what you read.

Using Org means that it’s easy for me to search my journal—where all these notes go—for a topic or tag. Regardless of the tools you use, taking notes on what you read is a great way of boosting your native memory.

For those who don’t know, deadgrip is an Emacs interface to ripgrep. It displays the results in an Emacs buffer along with some ancillary information. Check the example at the deadgrip link for some example output. Ripgrep, of course, is a powerful and speedy grep utility; deadgrep provides a nice interface for Emacs users. It’s a bit like counsel-rg but provides a little more context.

James Dyer is a deadgrep user but wanted a little more flexibility. Normally, he’d like to search for whatever’s at point and he almost always wants to search his entire user directory rather than the current directory. When he’s in a Dired buffer, though, he just wants to enter the search string because the Dired buffer mostly has file and directory names.

He has an alternate form that does the same thing but uses the current directory. Between the two functions he has most of his needs covered. The amount of code he needed for this is minimal and easily copied to your init.el. If you’re not a deadgrep user, you can very easily modify it to call ripgrep directly.

I’m happy with counsel-rg but if you’d like a slightly better display and a bit more flexibility, Dyer’s post is worth a look.

Years ago, I read and wrote about Ben Maughan’s excellent method of handling his email. It’s an inbox zero method that insists that for each message in your inbox you should

1. Read and delete it, or
2. Read and store it in a single folder, or
3. Read and store it in a single folder and act on it immediately, or
4. Read and store it in a single folder and create a TODO entry to act on it later

The important thing is that each message is acted on and removed from the inbox immediately. That makes it pretty easy to achieve inbox zero. When I first read Maughan’s post I was still using the Apple Mail app but I was immediately taken with his method and soon moved to mu4e, the mail client he used, and adopted his method.

That method works very well for me but some folks have a lot of email and require a more complicated method. Alain M. Lafon is, apparently, one such person and although he, too, uses mu4e, he uses the mu4e bookmark facility to organize his emails. You can read his post for the details.

For folks like me with a minimal email overhead, Maughan’s method is ideal. I’m inclined to think it would probably work well for those with more robust email requirements as well but I have no first hand evidence. If you think you need something stronger than Maughan’s method, take a look at Lafon’s post for another possibility.

Howard Abrams has a nifty idea. Open an Org file by its file name, title, or the tags it contains. If, like me, the majority of the files you deal with are Org files this make a lot of sense. When you call org-find-file instead of find-file, you get a list that contains the file name, title, and tags. Since it’s mediated by completing-read you can narrow down the choices in the usual way. Once you make a choice, find-file is called with the file name from the chosen entry.

The design of the command is interesting. Rather than build something like a TAGS file for use by the command, everything happens dynamically in real time. Abrams leverages the speed of the modern grep ripgrep to build the completing-read selection list on the fly. Of course, it’s a little more complicated than that. First, ripgrep is called to gather the titles and then it is called again to gather the tags in each of the files in the target directory.

Most of Abram’s code is concerned with putting together the information and formatting each entry into a nice looking line for the user to select from. The use of ripgrep makes most of it simple. The main difficulty is gathering the tags because they can appear in an Org file in a couple of ways—see Abrams’ post for the details.

If you’re interested in playing around with his code, it’s available in his GitHub repository. It’s a nice piece of engineering and well worth studying for its ideas.

Sacha Chua has a great post on using bug-hunter. She had a problem in her large Emacs configuration file and used bug-hunter to find it. If you’re like me—and apparently Sacha—you won’t use it very often but when you’re trying to track down an issue in your configuration, it’s just what you need. Every time I’ve used it, it found my problem quickly and easily.

For those not familiar with bug-hunter, it works by doing a binary search on your configuration: it loads the first half of your configuration and if the bug appears, it starts over loading the first quarter. If the bug is not present, it starts over loading the second half of the configuration. As with a traditional binary search, it recursively narrows down the line causing the problem until there’s only one left.

Sacha’s use case was a little unusual because the error happened asynchronously not at load time so she patched bug-hunter to capture when the offending application was being set up. Take a look at her post to see the details.

It’s a testament to the flexibility of bug-hunter that Sacha was easily able to coerce it into working for her situation. The usual use of bug-hunter is tracking down why Emacs won’t load but as Sacha’s post shows, it can be helpful in more general situations. The next time you need to figure out what part of your configuration is causing you a problem, you should give bug-hunter a try. It’s a great utility.