Irreal

As most of you know, I don’t use Gmail or anything else from Google—except YouTube—if I can help it. They have, sadly, moved from “Don’t be evil” to “Do whatever you need to do to make us money”. For reasons that we here at the Irreal bunker have a hard time understanding, lots of people disagree and are all in on Gmail and many of the other Google offerings.

If you’re one of those Gmail users, are running on a Mac, and are an Emacs user, you may want to read your Gmail from within Emacs. The problem is that it’s difficult to configure Gmail authentication. Yi-Ping Pan has a solution. He uses the Password app instead of OAuth2 and says that you can get everything set up in about 20 minutes. Take a look at his post for the details. He provides everything you need to get things running.

Webframp notes in a comment that Pan’s solution might not work if you have Google’s advance protection enabled. I can’t comment on that because: not a Gmail user.

Well, actually, I suppose that technically I am a Gmail user because I do have a Gmail address. I can’t remember the last time I got any mail from it but irrational paranoia keeps me from deleting it. How, then, do I deal with Gmail? Simple. I forward it do my main email account so that it appears normally without having to do anything special. Like many of you, I have several email accounts and I do the same thing with all of them: I forward them to my main email account. Mu4e makes sure that my answers come from the appropriate email address.

If you’re using Gmail as a secondary account, forwarding it to your main account may make more sense than jumping through Google’s hoops. Regardless, if you want to retrieve Gmail directly, Pan’s post has a good solution.

Just a quickie from Marcin Borkowski (mbork) today. Like many of us, mbork likes to turn on global-auto-revert so that any file open in Emacs that gets changed by an external process has the changes reflected in the Emacs buffer.

Sometimes, though, you don’t want that to happen. Mbork gives the example of viewing a PDF file while LaTeX is updating it. The question is: how to prevent auto revert from updating certain modes.

That turns out to be pretty easy. As usual, Emacs has us covered. The global-auto-revert-ignore-modes variable lists all the modes that should be ignored by auto revert. You can check mbork’s post for the details but it’s really quite simple: you list the modes that auto revert should ignore and that’s it.

This is, really, a niche concern but if you have it, mbork’s post tells you how to avoid it.

Today was a good Emacs day. I learned something new. Over at Ray on Emacs, Raymond Zeitler has a very nice post on using zap-to-char in reverse. He—hypothetically—was typing some text, inadvertently leaned on a key, and ended up with a long string of a repeated character at the end of his text. Something like this:

senteeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee

Here’s what I didn’t know. You can cause zap-to-char to delete characters to the left by giving it negative count argument. So in Zeitler’s example, he erases the string of e​s by calling zap-to-char as Meta+- Meta+z t.

But that’s not quite right. The problem is that it will also erase the t, which I assume was not his intention. Fortunately, there’s an easy solution that I wrote about almost 14 years ago. The problem with zap-to-char is that it does what you want it to only about half the time. The rest of the time you don’t want to delete the target character; you want to delete up to but not including that character. It turns out that Emacs has a command, zap-up-to-char, to do that but it’s not bound to any shortcut¹. I have it bound to Meta+Z. It also honors the negative count argument so the correct solution for Zeitler’s problem is Meta+- Meta+Z t.

The mistake aside, this is a great post because it tells me—and maybe you—something I didn’t know: you can zap backwards.

Last week I saw this post by Case Duckworth about Emacs bankruptcy but this post isn’t really about Duckworth’s post. Rather, it’s about the whole notion of Emacs bankruptcy and whether it’s something we should embrace as a routine activity. Some writers view it as part of the cycle of our Emacs life and recommend it as a regular activity.

As I wrote last year, my init.el is an organic entity that grows and adapts as my needs change. Sometimes I delete configurations or packages that I no longer use but most often I add a configuration or package as my needs change or I learn something new. I’ve put a lot of work into evolving my configuration and I can’t think of any reason that I’d want to abandon all that work and start over. Much better to fix the parts that need fixing and save the parts that are working.

My configuration is by no means a carefully considered project that has grown according to some master plan. Rather, it has evolved to meet my changing needs and newfound knowledge. Sometimes there are experiments that don’t work out and when that happens, I simply delete the offending lines and keep going.

At no point have I ever felt the need to just quit and start over. That strikes me as crazy. It is, I suppose, an Emacs specific example of the urge to scrap an existing system and rewrite it. As Joel says, that always ends in tears.

The TL;DR is that I reject the idea of Emacs bankruptcy and think that in almost every case, you should too.

Regular readers will be familiar with my occasional posts concerning my old pal Watts Martin’s journey into the Emacs event horizon. When he began, he swore that he would not be one of those “everything in Emacs” folks. He still (barely) hasn’t succumbed but the Borg are smiling and mumbling something about resistance and futility.

His latest step into the unknown frontiers of the black hole is adopting mu4e as his email client. It’s not an uninformed decision. Martin has tried lots and lots and email clients and mostly hates them all. As a long time Mac Head, he doesn’t care for the mu4e UI—it is, he says, the opposite of what a proper Mac app UI should be. But yet. It does have a lot of features that other mail clients don’t have. You can take a look at his post for the details.

Martin complains, rightly, that mu4e is hard to configure, especially considering that you also have to deal with isync/mbsync or something similar to retrieve email from it’s IMAP server. Longtime readers will remember my own struggles with that. I managed to avoid one of the problems that Martin dealt with by forwarding all my email accounts to a single account from which I retrieve them.

That saves a lot of trouble on the mbsync end but still allows me to handle each account separately within mu4e. If I answer an email, mu4e looks at the address the email was sent to and automatically sends it from the right address. If I initiate an email, it’s a simple matter to arrange it to be sent from any of my accounts.

Martin’s post on mu4e is actually a pretty good review of the app and worth looking at if you’re an Emacs user looking for a new email client.

Emacs’ shortcuts and their role in RSI are a staple of Emacs commentary. Everyone, it seems, has their own methods for relieving stress on their hands as they use Emacs. Prot, for example, thinks that one-shot modifiers are the answer. Others recommend using a split keyboard or simply mapping Caps Lock to Ctrl.

A post over at meanwhiling has another suggestion: use your thumbs. That’s also familiar advice but the post goes into specific details. Those details, in a nutshell, are to map the two keys nearest to either side of the space bar to Ctrl and the two keys next to those to Meta.

That setup has the advantages that

1. Both the Ctrl and Meta keys can be pressed with a thumb
2. There is a Ctrl and Meta key on both sides of the keyboard so you never have to press the modifier and target key with the same hand.

The only remaining question is what to do about Hyper and Super. I use both of those, especially Hyper, all the time so I need them easily accessible. That’s made easier for me because I don’t mind using the same hand for the modifier and target keys. I still use Caps Lock for Ctrl and my thumbs for everything else. If my pinky ever starts complaining about Ctrl I’ll probably just swap Ctrl and Super. I’d do that anyway except for muscle memory and the fact that my hands don’t hurt.

I do think using your thumbs for your most used modifiers make sense and modern keyboards make that pretty easy to set up.

Charlie Holland has a very interesting post about annotation in place. The idea is to take notes on digital content the same way you would if your were marking up a book or a physical paper. The important thing is that you don’t want to suffer a context switch disruption by switching to another app to take your notes and you want those notes to appear (even years later) when you revisit the file. A secondary consideration is that you want to be able to go not only from the text to the notes but also from the notes to the text.

There is—as we Emacsers always say—an Emacs package for that. That package is org-remark. It does its magic just as you’d expect. The notes are anchored in the text by highlighting the passage you’re writing about and the position of that highlight and its associated notes are kept in a separate Org file with enough meta data to get back to the original document.

The package comes with builtin support for several document types but Holland says that it’s pretty easy to add others and that in fact he’s added them for Elfeed, PubMed, and Wombag. The major shortcoming that I can see is that PDFs aren’t supported.

Holland’s post includes an 18 minute, 15 second video that demonstrates org-remark and provides a nice overview of the post. The post itself is long and comprehensive.

The org-remark package seems like a nice app that could be a big help for those of us that like to take notes as we’re reading. I could see myself using it to take notes on Web pages that I want to write about for Irreal. If it seems like it might be useful to you, take a look at Holland’s post.

Update [2026-05-21 Thu 13:48]: Added link to Holland’s post.