Irreal

One of the really nice features of Emacs is its builtin help system, which often results in Emacs being described as the self documenting editor. Experienced Emacsers usually take it for granted but it’s really a wonderful thing. There’s no need for storing or losing manuals; it’s all there all the time as part of the application.

Old hands take advantage of this documentation without thinking about it but n00bs may wonder how to get started. Davide Mastromatteo has an excellent tutorial on how to access the Emacs help system and use it effectively. He starts by mentioning the builtin tutorial and recommends that everyone go through it at least once. Fortunately, Emacs will remember where you left off so you don’t to complete it in a single sitting.

Next he mentions that the Emacs manual is also built in (in info format) and easily accessed with the Ctrl+h r sequence. I find it more convenient to access the Web version of the manual but it’s nice to have it available when I don’t have Internet connectivity.

From there Mastromatteo moves on to the three help commands most of us use the most: describe-key, describe-function, and describe-variable bound to Ctrl+h k, Ctrl+h f, and Ctrl+h v respectively.

Finally, he mentions the appropos command (Ctrl+h a) to do fuzzy searches of the help commands. If you’ve been using Emacs for a while, you’ve doubtlessly internalized these commands by now. If you’re new to Emacs, Mastromatteo’s post is definitely worth your while.

Just a quickie today. Here’s something I didn’t know:

> Converting to hexl format discards undo info; ok? (y or n)

I really admire how seriously Emacs looks after your undo state. Not enough software will warn you if you’re about to discard undo information.

— Wilfred Hughes (@_wilfredh) January 23, 2023

It’s nice to know that Emacs has our back and warns us when we’re about to lose information or state. I don’t think I ever converted to hexl so I’ve never seen this but it’s nice to know that Emacs, as always, is looking out for us.

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.