Wow, yesterday was nerve-wracking. Listening to the wind howl wasn’t great before we lost power, and it was awful after we did around 2:30 in the afternoon. Plus there are all the things that start making noise once the power is out, like the UPS and smoke detectors. And because of the extreme cold, one of the motorcycle disc locks started going off every ten minutes or so until I went out and got it loose and brought it inside to thaw.

Due to whatever local peculiarities in the grid, we could look out any window and see lights on around us after the sun went down, and when the Portland General map was willing to load we could see the outage reports disappearing all around us until we were part of a little island clustered around the neighborhood park.

Power outages aren’t rare in this neighborhood. I think before this one we’ve never gone more than eight hours or so. This time the lights stayed out until 5:30. It got down to 44 in the house overnight, and would have been worse if not for the gas fireplace holding the line until we went to bed.

Anyhow … no, it wasn’t great, but it was also not life in the RV across the street, or a tent a block away. We could still sleep in a bed, keep the phones charged, or take one of several friends up on an offer to come over if we needed to.

Junction, xdg-open, mutt and HTML mail

The whole “I want to use a plaintext mail client on a GUI desktop thing” has been messy for a super long time. Excavating my mutt mailcap, I can see a bunch of swings at it going back 15 years. I thiiiink I might have finally figured out a setup that’s still got a few rough edges but seems stable.

I’ve got Junction installed from a flatpak, and I’ve got it set as the default browser (in GNOME that’s Settings -> Default Apps -> Web), and as the default for the HTML file type (xdg-mime default re.sonny.Junction.desktop text/html).

In my ~/.mutt/mailcap I’ve got:

text/html; xdg-open %s &> /dev/null &; nametemplate=%s.html
application/*; xdg-open %s &> /dev/null &;
image/*; xdg-open %s &> /dev/null &;

mutt defaults to the plaintext version of a message when I open it, but I can tap v and select the text/html part to bring up Junction.

I tried living with w3m as my default text-mode browser for reading HTML mail inline, but once I started counting the number of times I went ahead and bailed to a GUI browser I realized it’s not a great experience. So I just let it display the plaintext version first, which is usually more readable than whatever w3m is going to render.

I also tried using Firefox as my default GUI browser for HTML mail, but I use Firefox for personal stuff and Chrome for work stuff, so it’s helpful to open an HTML mail in the browser that’ll have the right cookies.

So the net of it is:

• Junction can grab links from apps and pop up a selector, so a link from work Slack can open in Chrome and a link from a personal email can open in Firefox.
• Junction can send HTML mail to a chosen browser.

Making Chrome profiles available from GNOME launcher and Junction

When launched from Junction or the GNOME launcher Google Chrome will launch with a profile selector, which is fine: I have two profiles, but usually only use the work-related one. So as a matter of curiosity I wanted to see if I could get Junction to offer profiles instead of a generic Chrome icon. You just need to make .desktop files for each profile and tell Chrome the directory to launch from.

Running from Flatpak as I do, I don’t think Chrome’s quite “normal” so I made data directories for each of my profiles and then made a pair of .desktop files. They look like this:

[Desktop Entry]
Version=1.0
Name=Personal Chrome
# Only KDE 4 seems to use GenericName, so we reuse the KDE strings.
# From Ubuntu's language-pack-kde-XX-base packages, version 9.04-20090413.
GenericName=Web Browser
# Gnome and KDE 3 uses Comment.
Comment=Access the Internet
Exec= flatpak run com.google.Chrome %U --user-data-dir=/home/mph/.config/google-chrome/pdxmph
StartupNotify=true
Terminal=false
Icon=/home/mph/.local/share/icons/google-chrome.png
Type=Application
Categories=Network;WebBrowser;
MimeType=application/pdf;application/rdf+xml;application/rss+xml;application/xhtml+xml;application/xhtml_xml;application/xml;image/gif;image/jpeg;image/png;image/webp;text/html;text/xml;x-scheme-handler/ftp;x-scheme-handler/http;x-scheme-handler/https;
Actions=new-window;new-private-window;

[Desktop Action new-window]
Name=New Window
Exec= flatpak run com.google.Chrome %U --user-data-dir=/home/mph/.config/google-chrome/pdxmph
[Desktop Action new-private-window]
Name=New Incognito Window
Exec= flatpak run com.google.Chrome %U --user-data-dir=/home/mph/.config/google-chrome/pdxmph

The “Exec” lines are the pertinent ones.

Once set up, and after running update-desktop-database ~/.local/share/applications, Junction will pick them up as a pair of distinct browsers.

It’s a little hacky, and I think if you are running Chrome from outside Flatpak your approach will vary – there may be proper data directories in your .config hierarchy somewhere.

Vampire Survivors

Still playing. When you get to the late levels (approaching 100) or late into the round (approaching 30 minutes) and your weapons and powerups are maxed, it is almost psychedelic: Just thousands of creatures all running into this whirling, swirling vortex of destruction. The sound of all the weapons and powerups and exploding bad guys reminds me of being in the slots section of a busy casino.

I keep having to reinvent this every few years, and I always stitch it together from assorted sources, mostly because Google sort of shifts around now and then. So:

• Given a Gmail account with IMAP access turned on
• Given a Fastmail account using IMAP
• Given mutt, with your configuration in ~/.mutt and with muttrc and macros files.
• Given a working gpg config you can use to encrypt/decrypt

There are all sorts of ways to handle mutt config for assorted providers. The examples here are working right now, in early 2024. They probably have bits of cruft and lint because my config has been a work in progress since some time in the late 20th century.

Overview

You’re making profiles to do this: One for each of your accounts that will hold account specific config information. If you currently have a monolith config in mutt, you can lift a lot of stuff out of it and move it into a profile, then source the profile in your main muttrc.

You’re also going to make and encrypt a credential file for each account. Some people do this all in one file and use account hooks to make sure imap_user, imap_password and smtp_password are set correcctly depending on the account you’re operating in. I chose to make a file for each account.

You’re going to make macros that source the profiles when you want to switch between them.

0. Pre-config with Gmail and Fastmail

I’m not going to go into a ton of detail here:

• Gmail needs to have less secure app access turned on. Find it in your account settings. If you’re doing this for a work account, it may be your admin hasn’t enabled this. Have fun fighting city hall, in that case.
• If you have a GSuite admin, they need to have enabled all IMAP clients, not just OAuth ones.
• If you have 2FA turned on with Google, you will need to enable an application password.

For Fastmail:

• You need to have an app password set up for mutt. Settings -> Privacy and Security -> Integrations -> App passwords

1. The profile files

Make profile files for each of your accounts. I name them workplace.profile, fastmail.profile, etc. It doesn’t matter there’s no required convention. It’s a good idea to use the first one as the template for the second one.

This is an example of my Fastmail profile. Note line 6:

source "gpg -d ~/.mutt/passwords.gpg |"

That’s where your credentials will come from. I’ll show that file next.

# -*- muttrc -*-
# Mutt sender profile : personal/default

unset folder
set smtp_authenticators = 'gssapi:login' # fastmail needs this
set imap_authenticators = ''
source "gpg -d ~/.mutt/passwords.gpg |" 
set spoolfile = "imaps://imap.fastmail.com"
set folder = "imaps://imap.fastmail.com/INBOX"
set postponed="+Drafts"
set hostname="yourdomain.com"
set signature= "~/.mutt/personal.sig"
set from= "Bob Jones <bob@yourdomain.com>"
set realname = "Bob Jones"
set smtp_url = "smtps://bobjones@fastmail.com@smtp.fastmail.com:465" # use your fastmail username, not your email address
set imap_user = "bobjones@fastmail.com" # use your fastmail username here, too

# set the status to show which profile I'm using
set status_format= "-%r-Fastmail: %f [Msgs:%?M?%M/?%m%?n? New:%n?%?o? Old:%o?%?d? Del:%d?%?F? Flag:%F?%?t? Tag:%t?%?p? Post:%p?%?b? Inc:%b?%?l? %l?]---(%s/%S)-%>-(%P)---\n"

unmy_hdr *

my_hdr From: Bob Jones <bob@yourdomain.com>
my_hdr Organization: yourdomain.com
my_hdr Sender: Bob Jones <bob@yourdomain.com>
my_hdr Return-Path: <bob@yourdomain.com>

# clear the existing mailboxes list
unmailboxes *

# load up mailboxes appropriate to this profile
mailboxes + "=Spam"
mailboxes + "=disposable"
mailboxes + "=Newsletters"
mailboxes + "=Sent"
mailboxes + "=Archive"

2. Make credentials files

For each account, you need to make a file for your credentials.

set imap_user=bob@bobjones.com
set imap_pass="klatu barada nikto"
set smtp_pass="klatu barada nikto"

Name it whatever. passwords-accountname works.

Once you’ve created the file, encrypt it with gpg:

gpg -r your-gpg-key@yourdomain.com -e passwords-fastmail

Test it:

gpg -d passwords-fastmail.gpg

Then shred the plaintext original:

shred -u passwords-fastmail

Make sure that your profile (from the previous step) is sourcing the gpg file in line 6 of my example, e.g.

source "gpg -d ~/.mutt/passwords-fastmail.gpg |"

3. Do a quick mid-config check

Might as well test it now. You can do that by sourcing one of your profiles in your muttrc:

source ~/.mutt/fastmail.profile

When you run mutt the first time in this login session, you should get a gpg prompt for your credentials so mutt can decrypt your password file and use it to log in.

If it’s working, now’s the time to make your second profile and credentials files using the above steps since it’ll be good to know what they’re all called for the next step, which is making macros.

4. Make macros

I keep my macros in their own file under ~/.mutt just to keep things modular. You can put these in your main muttrc. Whatever you prefer. If you have a separate file, make sure to source it in muttrc:

source ~/.mutt/macros

Now add something like this for each account:

macro index .cf '<sync-mailbox><enter-command>source ~/.mutt/fastmail.profile<enter><change-folder>!<enter>'
macro index .cg '<sync-mailbox><enter-command>source ~/.mutt/google.profile<enter><change-folder>!<enter>'

That just does one last sync, then sources your profile, then changes folders to the inbox of that profile.

Restart mutt. From the index, if all is working correctly, the macro .cf will source your fastmail.profile and the macro .cg will source your google.profile file (both of which also source/decrypt their respective credential files).

5. In conclusion

Once it’s all wired up and running, you should be able to switch back and forth between accounts with just a few seconds of latency as the inbox syncs on exit and the new inbox syncs on login.

The pleasures of mutt

I went on a mutt revival kick early last year. It remains a land of contrasts. I never end up sticking to it 100 percent of the time but instead prefer to use it as a quick triage tool: It’s easy to make macros and keybindings that speed up inbox processing. Sometimes it’s easier to just bail out to the web mail interface, but during the day it’s helpful to just burn through the inbox never taking my hands off the keyboard.

mutt scoring and color treatments

One last thing, I guess, since I’m documenting stuff. One of the reasons I like mutt for triage so much is my ability to add a little visual treatment to messages based on their scores. That makes it easy to see what in my inbox has more priority.

I’ve got this little script in my ~/.mutt:

#!/usr/bin/env ruby

require 'mail'
require 'tempfile'

# Wants a +/- integer, e.g. +20
score = ARGV.first

score_file = "#{Dir.home}/.mutt/scored"

msg = Tempfile.new('msg')

msg.write($stdin.read)

mail = Mail.read(msg)

from = mail.from.first

File.open(score_file, "a") { |f| f.write "score ~f#{from} #{score}\n"}

msg.close

msg.unlink

And I’ve got these macros in my ~/.mutt/macros file:

# Score messages
macro index,browser .sp "<pipe-entry>~/.mutt/mailscore.rb +5\n<enter-command>source ~/.mutt/scored<enter>" # score sender +5
macro index,browser .sP "<pipe-entry>~/.mutt/mailscore.rb +20\n<enter-command>source ~/.mutt/scored<enter>" # score sender +20
macro index,browser .sm "<pipe-entry>~/.mutt/mailscore.rb -5\n<enter-command>source ~/.mutt/scored<enter>" # score sender -5
macro index,browser .sM "<pipe-entry>~/.mutt/mailscore.rb -20\n<enter-command>source ~/.mutt/scored<enter>" # score sender -20

And I’ve got a few lines in my ~/.mutt/colors file:

color index cyan default "~n 0-2 !~p"
color index magenta default "~n <5"
color index brightyellow default "~n >15"
color index brightred default "~n >19"
#

The macros pipe a given message into the script, the script extracts the sender, and the script writes a line into my ~/.mutt/scored file. Then the ~/.mutt/colors file (which you need to source in muttrc) assigns colors to certain scores. I have a few other rules in ~/.mutt/scores, as well:

# Date-based scoring penalties -- older things fall down
score ~d>3d -1
score ~d>7d -3
score ~d>14d -10

score "~O" +10 # old = +10 so I don't miss it
score "~F" +20 # flagged = +20 so it stays in the interesting view for a while, even if old
score "!~p ~d>7d" -10 # not for me directly, getting old, let it fade away
score "!~l" +2 # to a known list, give it a bump

I have a little self-control, so I made myself wait until I had mutt working before trying out mu4e.

And at that point, there was a yak capering about in my living room, and it had to be shaved:

• mu
• msmtp
• mu4e
• … and isync

isync because I found a bug in OfflineIMAP, which was inevitable given the 20-year-old email corpus I’ve been lugging around between mail servers. It was killing Homebrew’s ability to run offlineimap daemonized, so down that rabbit hole I went to satisfy myself the problem was widespread enough that it was worth considering alternatives, and isync has some good press.

Initial impressions:

• mu is pretty cool on its own. Very curious to play with my 20 years of email with it.
• I haven’t really tested mu’s performance under mutt with search. But it is nice having very fast address lookup.
• msmtp is … fine? I was using built-in SMTP for mutt, msmtp is there for mu4e’s benefit so I just use it for both clients now.
• isync seems fast enough and works well once the initial mail store is read into maildir.

Tomorrow I’ll move the data and databases over to my desktop

Oh … mu4e.

It is weird, but it’s my kind of weird. Very high concept. Super fast. The “squee” factor is being able to compose mail in org-mode markup, which it turns into multipart mail. If you read the HTML version of your mail, mu4e messages look like rich text. If you read the plaintext version, it applies some plaintext styling:

Heading
═══════

*Bold* and /italics/ and [a link].


[a link] <https://mike.puddingtime.org>

Subheading
──────────

Search is superfast, navigating between folders is keyboard-centric, and because the mail retrieval stuff is happening outside of an Emacs thread, it doesn’t block. I think you can set it up to run isync async inside Emacs, but I just noticed someone’s config a few minutes ago and it’s bedtime.

I am not sure what its future will be. I really like my mutt setup. I wonder if there’s a way to get the org-mode mail composition using Emacs as my mutt mail editor. Science needs to be done.

And because I’ve chosen to treat org-contacts as TODO items for purposes of remembering who to PING, FOLLOWUP, SKED, etc. it has to take the extra step of stripping those keywords from the returned name. Otherwise, my mails to Joe Grudd would be addressed to FOLLOWUP Joe Grudd.

That’s a small bit of inelegance in my plaintext CRM setup: As I’ve figured out more about how org-super-agenda works, I’ve had glimpses of how the plaintext CRM metadata could just be content in the :PROPERTIES: drawer, and hence invisible for purposes of tools like this, but a few other pieces of passive automation would have to become some sort of org-mode hook and I’d lose the utility of tools like Beorg, which can’t provide the automation of native Emacs.

For now, it’s one of those “this design isn’t the cleanest, but it’s simple and only creates a few easily solved problems” things.

Here’s the script itself. I put it in ~/bin as orgcontact.rb:

#!/usr/bin/env ruby

# Get the query string
query = ARGV[0]

# Set the path to your Org-contacts file
orgmodefile = "#{ENV['HOME']}/org/contacts.org"

# Read in the whole contact file
raw_contacts = File.read(orgmodefile).split("\n** ")

# Iterate through each contact
raw_contacts.each do |contact|
  if contact.match?(/#{query}/i)
    # Extract the name and email from the contact
    name = contact[/^[^\n]*/].gsub(/(PING|INVITE|WRITE|PINGED|FOLLOWUP|SKED|NOTES|SCHEDULED|TIMEOUT|OK)\s+/i, "").strip
    email = contact[/:EMAIL:\s+(.*)$/, 1]
    # Remove tags from the name
    name.gsub!(/:\S+:/, '')
    puts "#{email}\t#{name}\t(org-contacts)" if name && email
  end
end

Adding m_org_contacts to the METHODS setting then including a little wrapper in ~/.lbdbrc doesn’t follow the canonical advice on how to configure an lbdb backend, but it works, and it’s one less file to put somewhere:

METHODS="m_osx_addressbook m_org_contacts"
MODULES_PATH="$MODULES_PATH $HOME/bin/lbdb"

m_org_contacts_query() {
   ~/bin/orgcontact.rb "$1"
}

So, the outcome is just:

1. Start a new message in mutt and start typing the name/address/etc.

2. lbdb provides a list of matches from a few sources I’ve set up: org-contacts and macOS address book

3. ENTER to select a candidate

   b

Mutt does, however, have pretty good facilities for scoring individual properties of a message, then do different color treatments for a given message’s score in the index. Scoring and coloring can be driven by mutt’s extensive list of search patterns..

This is a lightly annotated selection from the top of my mutt scores file, which I source in ~/.mutt/muttrc at startup:

# -*- mode: conf-unix -*-
# Mutt scoring file

unscore * # start fresh
score ~p +5 # Mail addressed to me or one of my alternates gets 5 points

# Date-based scoring penalties -- older things fall down
score ~d>3d -1
score ~d>7d -3
score ~d>14d -10

score "~O" +10 # "Old" in mutt is "seen but unread". +10 so I don't miss it
score "~F" +20 # flagged = +20 so it stays in the interesting view for a while, even if older
score "!~p ~d>7d" -10 # not for me directly, getting old, let it fade away
score "!~l" +2 # to a known list, give it a bump

Given some scores, you can add color treatments:

color index white default "~n 6-9"
color index white red "~f trimet ~s Service\\ Alert"
color index brightblack default "~f trimet ~s Service\\ Alert ~d>1d"
color index magenta default "~n <5"
color index brightyellow default "~n >10"
color index brightred default "~n >19"

Adding a score to the scores file manually is no big deal. Mine tends to include specific people, work email lists, things I definitely don’t want to miss (e.g. service alerts from TriMet), and things that I should keep seeing but want to deemphasize (like business messages from hosting providers). But it’d also be nice to do some scoring as I’m reviewing mail to deal with new important senders, necessary nuisances, etc.

So I wrote some ruby and mutt macros that let me pipe a given message into a script that extracts the sender and writes a +/- modifier to their score in a scored file I source alongside my scores file.

#!/usr/bin/env ruby

require 'mail'
require 'tempfile'

# Wants a +/- integer, e.g. +20
score = ARGV.first

score_file = "/Users/mph/.mutt/scored"

msg = Tempfile.new('msg')

msg.write($stdin.read)

mail = Mail.read(msg)

from = mail.from.first

File.open(score_file, "a") { |f| f.write "score ~f#{from} #{score}\n"}

msg.close

msg.unlink

Pretty much just “parse the mail for the first from address, wrap it in a mutt score stanza, tack that on to the end of scored.”

Then I added some macros:

# Score messages
macro index,browser .sp "<pipe-entry>~/.mutt/mailscore.rb +5\n<enter-command>source ~/.mutt/scored<enter>" # score sender +5
macro index,browser .sP "<pipe-entry>~/.mutt/mailscore.rb +20\n<enter-command>source ~/.mutt/scored<enter>" # score sender +20
macro index,browser .sm "<pipe-entry>~/.mutt/mailscore.rb -5\n<enter-command>source ~/.mutt/scored<enter>" # score sender -5
macro index,browser .sM "<pipe-entry>~/.mutt/mailscore.rb -20\n<enter-command>source ~/.mutt/scored<enter>" # score sender -20

They just pipe the message into the Ruby script with a scoring argument, the script modifies scored, then the macro re-sources scored so the index reflects the new scoring.

Tapping .sp (score plus) in the index scores a sender up, .sm (score minus) scores them down. .sP and .sM are embiggened scores.

The way mutt works, it doesn’t accumulate these pluses and minuses, so when it parses the scored file it’s just going to use the last modifier I added. That seems fine, since they’re broad and there are other scoring factors at work. Over time the file will get long. Maybe the right thing to do is read the file in, try to match on a sender, and overwrite their entry, just to cut down on duplication.

The net effect of the current system is that the index is color-coded into four broad tiers: The super important, the pretty important, kinda average and should be read, and not particularly interesting and maybe worth an unsubscribe.

In the past, when I’ve gone through a plaintext or Emacs kick of some kind, I’ve blown past what I’ve come to think of as a common sense limit: Eventually I’m looking at Wanderlust, GNUS, or mu4e and thinking about the whole email in Emacs thing. Inevitably, then, you’re looking at some sort of way to sync your IMAP account down to your local machine, and a whole layer goes in to make that work.

I walked up to the line this time around, asked myself what problem I’m trying to solve, and remembered that part of what is making Doom Emacs work for me right now is how much I’ve been keeping things limited to stuff that has to do with writing and stuff that has to do with personal organization. Those are things that don’t stress Emacs’ single-threaded nature the way I do them, and that don’t take me into the murky space between Emacs and the OS.

The problem I am trying to solve whenever I go on these kicks, is the pain of getting parts of the macOS experience into a more keyboard-centric place. Mail always sticks out because I don’t like doing Mac Mail from the keyboard. There’s Mail Act-On, but at $45 a renewal it’s just more than I can see paying, and it doesn’t really do much for visualization – it just makes it easy to move things into folders.

So my mind always goes to mutt. It’s not perfect – search is a challenge without something external augmenting it – but I’m not sure it matters in the end: I use Fastmail for IMAP, and I don’t mind punting to its web interface if I need to go dig for something.

I thought about mutt this time because my long-standing config has always sort of felt similar to the way Spacemacs and Doom put a modal UI over Emacs. My mutt macros – here’s a sample – use . as a leader and are written mnemonically:

macro index .sn "l ^a^k~N\n" # Show unread/new only
macro index .sa "l ^a^kall\n" # show all
macro index .C "<esc>V" # toggle threads
macro index .si "l (~n5-100|~N)\n" # show interesting 
macro index .rs "<enter-command>source ~/.mutt/scores<enter>" # reprocess scores
macro index .sf "l ~F\n" # show flagged
macro index .hl "l ^a^k!~l\n" # hide lists
macro index .to "T ~d>7d\n" # "tag old" -- messages older than 7 days
macro index .ab    "<pipe-entry>/opt/homebrew/bin/lbdb-fetchaddr\n"                # Store address details in lbdb.

The value of mutt is less as my everything email client – I still keep up with mail from my phone or tablet – and more because over the years I’ve tuned it to visualize and process mail from the keyboard. I still read mail with my phone or tablet every day, but don’t like to do anything more than flag messages when I’m out.

HTML mail and mutt

mutt is sometimes hard to stick with because we lost the plaintext email battle. I know one designer who formats his email with monotype faces in what I’d describe as a sort of problematic aesthetic revolt, but otherwise … we lost and we’ll never be able to unsee Calibri.

Sticking elinks, lynx or w3m in your ~/.mailcap to show HTML was best practice for a long while, provided you didn’t mind also using urlview to display the links in a message once you’d read it. I was involved in email marketing during the era when that approach worked, partially because to do HTML mail “right” back then meant you had someone doing it painstakingly by hand, then reviewing across a multitude of clients and platforms – you were heavily incentivized to keep it simple. I bear the scars from a spat with a division of Siemens that was still using an old Lotus Notes and Win2000 in its marketing department. They were the customer, and the mail didn’t look good to them, so it didn’t look good. That was all, and we were forced to buy the next tier of service from our mail provider so we could add Lotus Notes on Win 2000 to our testing.

Anyhow, “elinks in your mailcap and call it a day” doesn’t work anymore: image text, dozens of links, complex positional markup, etc. etc. etc. and it makes a lot of HTML mail a hash in a plaintext browser. There are a few ways to solve this on a Mac: One is punting to an actual browser, and the other is using the Mac Quicklook service:

text/html;  open -a firefox %s; nametemplate=%s.html text/html; open -a firefox %s; nametemplate=%s.html; copiousoutput
text/html; qlmanage -p %s; nametemplate=%s.html

The former does about what you’d expect from looking at it: It uses Firefox (or whatever browser you’d care to invoke) to open the HTML part of the message, at which point you can click links, etc.

The latter is a little more obscure, but basically recreates what happens when you select a file and tap the spacebar to preview it on a Mac, popping up a modal window with the contents. This often works well for other kinds of attachments. With HTML mail it is enough to let you read the mail but not really interact with it (e.g. follow a link). The [DEBUG] label at the front of the modal’s title suggests that nobody at Apple really took the “plain text zealots using this to browse HTML email” use case into account when they wrote qlmanage, and the man page makes clear it’s just a debugging tool. It’ll do if you never intend to interact with a mail.

I’m sticking to the Firefox approach. It’s super fast if Firefox is already running (it always is), and you can follow links.

These things leave in waves, too

At some point mutt is going to do something to annoy me. I don’t know what it’s going to be this time. For now, I’m just enjoying the periodic dustoff of my config and pleasures of zipping through my inbox. If I had to guess, it’ll have something to do with getting email messages into org-mode or calendaring, somehow. There are a few shell-based CalDav clients out there, but they’re very sync-and-cache oriented and I just don’t like adding services. Had mutt never added IMAP caching and built-in SMTP support, I would have a harder time justifying it.

But I feel more protective of my Emacs and org-mode experience than anything. This run with Doom has yielded the most stable Emacs experience I’ve had since switching to Macs mooostly full-time ca. 2004. No mystery segfaults. No hard-locking the UI because I have IMAP, RSS, IRC, and Twitter clients running in my text editor.

For all of its talents, mutt doesn’t choose to expose any message variables to its macro functionality. If you want to extract a sender’s name or email address or whatever, the message has to be piped. I put something like that together to add senders to a mutt score file, and there are a few other things out there in the mutt ecosystem, like lbdb, that capture email addresses. lbdb could have been great for this, but its whole point is capture to a database of its own.

I’ve been poking around with getting ChatGPT to write little utilities for me, so I put this problem to it, asking for a Ruby script that could pipe a message through formail to extract the needed name and email address.

It took a second prompt – initially it just wrote the code to process the input without specifying the input – but it produced something workable to get the two pieces of data out, and I added an org-contacts template as a HERE doc the script writes into a mutt_contacts.org file. I could have sent it straight to contacts.org but prefer to automate into buffer files to keep the chance of conflicts, sync or otherwise, to a minimum.

The accompanying mutt macro looks like this:

macro index,pager .oc "|~/.mutt/org_contact.rb\n"

I tap .oc when positioned on a message and it pipes into the script.

I’d like to extend the macro to include a quick note, but for now it just adds the NOTES todo state and schedules the entry a day out to remind me to put something in there soon: The new entries turn up in my org-mode agenda for processing and re-filing into my contacts.org file.

And it worked well enough: Once I set it up I was able to run through and add nine or ten new contacts in a few seconds, then visit them in org-mode and refile them all.

And yeah …still holding the line against adding an MUA to Emacs proper. I just don’t want to do the whole OfflineIMAP thing or similar, and I am still keeping things relatively simple. Adding org-caldav today was a small step in the wrong direction, but I like having calendar entries in my org agenda, it syncs relatively quickly once it does the initial download, and it has no system dependencies.

#!/usr/bin/env ruby
require 'open3'
require 'date'
contacts_file = "~/org/mutt_contacts.org"
message_contents = $stdin.read
# Define the command to extract headers with formail
command = 'formail -X From: -X Sender: -X Reply-To: -x To: -x Cc: -x Bcc:'

# Execute the command and capture the output
output, status = Open3.capture2(command, stdin_data: message_contents)

if status.success?
  email = nil
  name = nil
end
  # Parse the output and extract the email and name from the From, Sender, and Reply-To headers
  output.lines.each do |line|
    case line
    when /^From:\s*(.*)$/i, /^Sender:\s*(.*)$/i, /^Reply-To:\s*(.*)$/i
      from = $1.strip

      # Extract the email and name from the From, Sender, or Reply-To header
      if from =~ /(.+?)\s*<(.+?)>/
        email = $2
        name = $1.strip
      else
        email = from
        name = "No Name Found"
      end

      # Found the email and name, so break the loop
      break
    end
  end

org_template = <<~TEMPLATE

  ** NOTES #{name} :mutt:
  SCHEDULED: #{(Date.today + 1).strftime("%Y-%m-%d")}
  :PROPERTIES:
  :EMAIL: #{email}
  :PHONE:
  :BIRTHDAY:
  :CONTACTED: #{Date.today.strftime("%Y-%m-%d")}
  :END:

TEMPLATE

File.open(contacts_file, "a") { |f| f.write org_template}