Irreal

Mike Zamansky has another video up in his Using Emacs Series. This time it’s about the Notmuch email client and how it compares to mu4e. Zamansky uses mu4e for his work email and Gmail for his personal email but decided he’d like to do all his email chores from Emacs. It’s pretty easy to set up mu4e to work with Gmail but Zamansky thought he’d look into the Notmuch client to see if he liked it better than mu4e.

They’re actually pretty similar except for how they organize your emails. Mu4e puts your emails in folders. That’s not as onerous as it might sound. Both Zamansky and I basically just use Inbox, Archive, and Trash folders to hold everything. Notmuch uses tags instead so if you want to save a particular email, you’d just tag it with ARCHIVE. You can, of course, use any tag(s) you like so it’s easy to organize your mail. As with mu4e, you locate emails with the powerful Xapian-based search functionality they both provide.

Although I love mu4e and have no plans or desire to change, there are folks who are just as passionate about Nomuch. Many of them tried mu4e first so their preference is not just “it’s what I use so it’s best.” The use of tags is a very nice feature and a powerful way of handling your email. You can, of course, use the tags to essentially replicate mu4e’s folder system if you like to organize your email that way but ever since I read Ben Maughan’s post on how he handles email with mu4e by keeping everything in a single archive folder, I’ve been a big believer in that method. I don’t need to use brain cells trying to decide which folder to store an email in. I just put them all in the same place and rely on the mu4e’s powerful search capability to find them when I need them.

So what did Zamansky decide? He says he likes Notmuch a little bit better but in the end his choice came down to a mundane pragmatic issue. Watch the video to see what it was. The video is 19 minutes, 40 seconds long so plan accordingly. As always with Zamansky’s videos, it’s well worth the time.

Very fast, it turns out. Arne Babenhauserheide has a great twitter thread on how fast ripgrep is:

yes, this is “ripgrep is so fast that I can simply grep through 2 million lines of code for each line in this file”.

It’s so fast that I was able to switch from IntelliJ “find-reference-in-index” for JS development to #Emacs dumb-jump “ripgrep all code for lang-specific regex”.

— ((λ()’Dr.ArneBab)) (@ArneBab) January 17, 2020

You should click on the tweet to see the full thread but a précis is that Babenhauserheide extolled the performance of ripgrep by noting that he was able to check the usages of over 200 property-keys in 2,000,000 lines of code in less than 5 minutes. That’s technically true but significantly understates ripgrep’s performance.

The author of ripgrep, Andrew Gallant, responded that that seemed slow to him and after some back and forth it turned out that the process actually took 46 seconds. Gallant says that still seems slow but guessed that it’s because ripgrep was being called once for each of the more than 200 property-keys.

Babenhauserheide ends the thread by saying he was able to replace IntelliJ’s find-reference-in-index by using Emacs with dumb-jump. I do the same thing and have been very happy with the result. Dumb-jump is essentially instantaneous with ripgrep even for fairly large codebases.

I’ve written a few posts lately about working in the Slime and Geiser environments to write and experiment with Common Lisp and Scheme code. What’s great about them is that they enable an “interactive programming” style where you can try out small code snippets to see what happens and build those small snippets into larger bodies of code. The snippets can be as small as a single expression. My two go to examples of this are the beginning of Magnar Sveen’s Web Rebels talk and Kris Jenkins video on building a Spotify client. You can find links to both of those in this post from 2013.

Of course, you can write Elisp this way too and the other great thing about Slime and Geiser is that they, too, run in Emacs. That means you can write, test, debug, and run your code from the comfort of Emacs. Why would you want to write code any other way?

Mike Zamansky has been experimenting with another language that enjoys a similar environment: ClojureScript. As with Common Lisp and Scheme, Emacs provides an interactive environment for ClojureScript: Bozhidar Batsov’s excellent Cider. In his second video on ClojureScript, Zamansky continues with the application he started in Using Emacs 63 that I wrote about here.

The video isn’t really about using Emacs but Emacs nevertheless plays a large and important role. Zamansky shows how easy it is to try things out and track down bugs while working on an application. Because Zamansky is a ClojureScript n00b, the ability to try something to see if it does what he expected and change things if it doesn’t is invaluable. It’s another example of the power of interactive programming.

The video is just short of 26 and a half minutes so you’ll definitely need to schedule some time but I found it interesting, enjoyable, and well worth time time.

If you’re an Emacs user who works primarily on some sort of Mac, you may be interested in a post by Nick Drozd in which he suggests a keyboard layout for avoiding pinky fatigue and all that goes with it. The TD;DR is that he switches the ⌘ Cmd and Ctrl keys in Emacs and then maps Caps Lock to Ctrl at the system level. That gives you a Ctrl and Meta key on both sides of the keyboard and they can both be reached with a thumb rather than a pinky finger. Drozd gives you the Emacs settings for switching Ctrl and ⌘ Cmd and, of course, you can map Caps Lock to Ctrl by clicking on the Modifier Keys button on the Keyboard pane of System Preferences→Keyboard. Drozd’s settings also map the fn key to Hyper. I’ve used that to give me a Hyper key for many years and really like it. It doesn’t interfere with the system function keys so you have the best of both worlds.

I haven’t tried this yet because I’m worried that it will mess up my muscle memory for the ⌘ Cmd key. It’s probably not a big deal so I’m still considering it. If you’re not worried about such things, give Drozd’s system a try. It’s easy to set up and easy to back out if you decide you don’t like it.