Irreal

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.

In my post on Omar Antolín Camarena’s May Emacs Carnival contribution explaining his reasons for using EWW as his default browser, I mentioned that Camarena said that one of the benefits of EWW not supporting JavaScript is that JavaScript is mostly used to make the user’s experience worse by doing things like loading ads, reconfiguring the user’s display parameters, and implementing paywalls.

If you had asked me, I would have said that any site using a paywall would also require JavaScript to load the content and, indeed, that’s true for some sites such as The New York Times but, as I discovered, it’s not true for a surprising number of sites.

After reading Camarena’s post, I decided to experiment a bit to see if it was possible to bypass paywalls simply by not running JavaScript. I mostly don’t care about paywalls because the majority of the sites that use them don’t have content that’s worth the effort of avoiding them. Still, I thought it would be interesting to test if the strategy was feasible.

I did this by opening any site that popped up a paywall in EWW. It worked for a surprising number of sites. Again, it’s almost never worth the effort but if you happen upon an article that you really want to read on a site that wants you to sign up for an outrageously expensive subscription, it may be worthwhile seeing if you can open it in EWW,

The other thing I learned is that reading content with EWW can be a very restful experience. No ads, no blinkenlights, and sometimes, no paywall either. I didn’t try running EWW with eww-readable but that would probably make the experience even more restful.

Marcin Borkowski (mbork) really likes all the ways you can mark files in Dired but noticed that an easy way to mark recently modified files was missing. He knows quite a bit about writing Elisp so it was an easy decision to decide to write some code to implement the missing feature.

The code, which you can see at his post, is pretty simple and easy to follow. What wasn’t so easy were some annoying design decisions. For example, what constitutes the current day? Is it 24 hours ago until now or is it the previous midnight until now? And by the way, should that be UTC or local time?

The natural interface is to specify the number of previous days you want to mark as a prefix argument but that leaves open the question of how to unmark the last n days. The natural solution—and the one mbork chose—is to use a negative n to mean “unmark the last n days”. So positive n, mark files modified in the last n days; negative n unmark file modified in the last n days. What about 0? Mbork made the arbitrary decision to have that mean mark files modified in the last 60 minutes.

There are a couple of other nuances that you can read about in mbork’s post. The real takeaway for me is how tricky it can be to get the small details right. That seems especially true when you’re dealing with time calculations. Questions like, “What, exactly, does ‘yesterday’ mean” turn out to be a lot harder to answer than they first seem. Take a look at mbork’s post to see what I mean.

I see a lot of blog posts recommending EWW. Sometimes I even write about them. The common theme is something along the lines of, “No, you can’t really replace a full-fledged browser with EWW but you can do a lot and a ”real“ browser is only a keystroke away.”

In another May Emacs Carnival entry, Omar Antolín Camarena offers his reasons for using EWW. He agrees with the conventional wisdom that EWW isn’t a replacement for a normal browser but that it is useful in many situations and even has some advantages over your default buffer.

He believes that one of the chief advantages of EWW is that it doesn’t run JavaScript. That’s ironic, of course, because EWW’s lack of support for JavaScript is one of its most oft cited shortcomings. But Camarena says that lack is often an advantage because JavaScript is often used to load ads or a paywall or to reconfigure your display preferences often choosing low contrast colors that are hard for anyone but the young to read.

His second reason for using EWW is that it brings the power of Emacs to your Web browsing. Among the advantages he lists are:

• You can easily resize images without changing font and other sizes.
• You can read the Web site content in multiple columns using follow-mode.
• You can use occur for a search and keep a list of results and easily navigate among them.
• You can evaluate ELISP directly in the EWW buffer and many other language as well with a bit of plumbing.
• You can use eww-readable to eliminate a lot of the junk that comes with many Web pages.

And, as Camarena stresses, you can always escape to a normal buffer with eww-browse-with-external-browser, bound to & by default.