Now I have two scripts for bookmarking in Newsboat, but it only has one reserved key for bookmarking a post. It does have macros, though, so you can use one to set the bookmarking command to a given script and bind it to something memorable. My mutt convention is to lead macros with a period, so I kept that here by unbinding Newsboat’s default macro prefix (,) and setting “.”.

So, .l to save to Linkding, .w to save to Wallabag:

# macros
bind-key . macro-prefix
unbind-key ,
macro w set bookmark-cmd "op run --env-file=\"$HOME/.env\" -- ~/bin/wallabag.rb"; bookmark
macro l set bookmark-cmd "op run --env-file=\"$HOME/.env\" -- ~/bin/linkding.rb"; bookmark

And here’s the Wallabag bookmarking script:

#!/usr/bin/env ruby

require 'httparty'
require 'json'

entry_url = ARGV[0]

wallabag_url="https://reader.example.net"

client_id = ENV['WALLABAG_CLIENT']
client_secret = ENV['WALLABAG_SECRET']
username = ENV['WALLABAG_USER']
password = ENV['WALLABAG_PASSWORD']

token_params = {grant_type: "password", client_id: client_id, client_secret: client_secret, username: username, password: password}
token_req = HTTParty.post("#{wallabag_url}/oauth/v2/token", body: token_params)
access_token = token_req["access_token"]

headers = {'Content-Type' => "application/json", 'Authorization' => "Bearer #{access_token}"}
params = {url: entry_url, starred: 0, archive: 0}
resp = HTTParty.post("#{wallabag_url}/api/entries.json", body: params.to_json, headers: headers)

Newsboat is pretty cool! It’s a plaintext RSS reader that has strong affinities for mutt in look and configuration.

Like mutt, it might not crowd out everything else in the toolbox but it can help you burn through the subscription list and triage even if you have more comfortable ways of reading the content you process.

It also has built-in filtering. If you’re using an RSS provider that already does that, e.g. FreshRSS or Feedly, that might not be super valuable, but it’s easy to make a killfile either way:

ignore-mode display
ignore-article "*" "link =~ \"/ducks/\""
ignore-article "*" "link =~ \"/advice/\""
ignore-article "*" "link =~ \"/nfl/\""
ignore-article "*" "link =~ \"/beavers/\""
ignore-article "*" "link =~ \"/blazers/\""
ignore-article "*" "link =~ \"/highschoolsports/\""
ignore-article "*" "link =~ \"/entertainment/\""
ignore-article "*" "link =~ \"/realestate-news/\""
ignore-article "*" "link =~ \"/food/\""
ignore-article "*" "link =~ \"/hawks/\""

Scripting the Linkding API to make a bookmark function for Newsboat

If you like reading longform plaintext maybe Newsboat is all you need. I tend to treat RSS as a two-step process: See an interesting thing, send it to some sort of RIL or bookmarking service. Newsboat has a bookmarking function you can customize with your own scripts. It just passes the article URL, title, description, and website description to your script, which has to talk to whatever API. There are a bunch of examples in the Newsboat contrib directory for things like Pocket, Pinboard, and Evernote. No Linkding, but the Linkding API is simple enough.

Could be simpler but I bounced off of net:http in my formative years:

#!/usr/bin/env ruby

require 'httparty'
require 'json'

linkding_uri = "https://links.puddingtime.net/api/bookmarks/"

# Get your Linkding API key from Settings > Integrations

token = ENV['LINKDING']

link_url = ARGV[0]
link_title = ARGV[1]
description = ARGV[2]
website_title = ARGV[3]

params = {url: URI(link_url), title: link_title, website_title: website_title, unread: true}
headers = {'Content-Type' => "application/json", 'Authorization' => "Token #{token}"}

resp = HTTParty.post(linkding_uri, body: params.to_json, headers: headers)

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

Looking around for other people who have done CRM/PRM-ish things in plaintext, I found JacobEvelyn/friends. It’s written in Ruby, uses Markdown for its home format, and gives you a command line interface to a record of your friends and activities. I appreciate how thoroughly it thinks about what it is trying to do, and I sense a set of concerns similar to mine about the “keeping up with personal contacts” challenge.

Some things I like about it:

• Simple CLI data entry syntax
• Some “habit tracking” style reporting to help you understand if you’re keeping up your practice.
• Clean reporting with a lot of flexibility that would let you build more reporting.
• Simple use of Markdown, with no elaborate syntactical overlay. If you gave up on friends, your data would be easily readable.

It’s probably good to note that friends isn’t a full contact management system. It’s better to think of it as a sort of journaling and habit tracking tool with a tight focus on keeping up with people, not a way to manage all your contact details. If I could extend one thing about it, it would probably be to be able to store email addresses with contacts: Email addresses aren’t great keys, but also they’re fine keys sometimes, and they’d open friends up to interacting with other tools.

ox-json and the wisdom of Neil McCauley

As I was looking through the docs for friends and waming up to it some I wondered how readily I could migrate my org-contacts information. My home language is Ruby, so I tend to start there when I’m looking for a library. There’s one org-mode gem I’m aware of, but its primary preoccupation is converting org-mode to HTML or Textile for presentation purposes.

Another way to come at the problem is to get the org markup into something more universally parseable, which is where ox-json could help. Does what it says on the tin: Converts an org-mode file into JSON, including, crucially, the data stored in the :PROPERTIES: drawer. Currently it passes by the :LOGBOOK: drawer, so that limits what you can do with it, but it still opens up possibilities.

Why?

ox-hugo update

I started blogging with ox-hugo several weeks ago, going into it a little warily.

Recap:

• You write all your posts in a monolithic org-mode file.
• Each heading is a post.
• Heading tags become post tags.
• Headings in a TODO state are drafts.
• Metadata can be stored in the :PROPERTIES: drawer (tidy, but the templating syntax gets cluttery if you’re not a lisp native) or additional metadata src blocks (more visually cluttered when writing, but easier to read the template if you’re a YAML native)
• You can set it up to automatically export the Markdown version into your Hugo content hierarchy whenever you save the buffer.

Why would you want to do this?

As someone who does a lot of digest posts, I like having my pre-publication notes, links, etc. in the org-mode ecosystem, with all of its text manipulation affordances. If a topic I’m working on isn’t ready when it’s time to publish that day, I just refile the subheading under my * Daily Post Overflow heading and keep going. I also like org-mode’s structure editing features. It’s simple to move headings and their content around within a post.

I thought the “all-in-one-file” thing would annoy me, and there is part of me that still doesn’t like seeing all the surrounding context, but that’s what subtree to indirect buffer is for. I drop into an indirect buffer for the long-haul writing, then pop back out of it if I need to pull things in from the overflow area or check on something from a previous post.

I did stub my toe on one thing, which was that the org-capture template I found to make the post setup simpler was setting :EXPORT-HUGO-DATE:, which updates dynamically when you save a post heading. I went back to make some edits to a post, saved my work, and it altered the date metadata in the Markdown output and jumbled my post order. The answer seemed to be to switch that to :EXPORT_DATE:, and now it behaves.

I also put off cleaning up my capture template so all the metadata could go in the :PROPERTIES: drawer. At first It was easier to just embed some YAML at the top of the post body with #+begin_src yaml :front_matter_extra t rather than working out the Lispier syntax for post image and cover image in the context of writing a capture template. It just took a few minutes to fix once I decided to bother with it, and the template now outputs :PROPERTIES: metadata:

:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :cover '((image . "" ) (caption . "" ))
:EXPORT_HUGO_CUSTOM_FRONT_MATTER+: :images '(/momo-logo.jpg)
:EXPORT_DESCRIPTION:

I only sometimes use cover images, but I like to include my site logo in social posts, etc. when I don’t have some other image to show, so the template defaults to an empty cover image and image metadata that Hugo’s OpenGraph templating can pull in.

Several weeks in, I like the workflow. One tiny part of my soul is troubled that I have org source and Markdown output, but on the other hand the org source overwrites the Markdown output on edit, so the two don’t drift. Realistically, the Markdown would be the more migratable content were I to shift off of Hugo, and it’s simply better to author in org-mode. So there’s no associated toil and each format gets to be useful in the way it is best suited to be so.

That Royal Enfield Himalayan

I complained a little about my Royal Enfield Himalayan a few days ago: a little big for the power it has, and it had some QA problems that took some time to track down I am pretty sure I am going to sell it to fund something similar. But I did swap in a fresh battery and cleaned it up from winter storage, and rode it up to St. Johns for lunch yesterday, which meant a few dozen miles. It ran pretty well!

Last year, after dealing with rough idling and stalls, I finally broke down and installed a BoosterPlug. Himalayans run too lean out of the factory, and the difference after installing one was pretty amazing. It was about a five-minute operation and it made the difference between a very rough first five minutes and “let it idle for 30 seconds and it’ll be fine.” The machine never stalls now. I do think it still idles a little low, but that’s a fine-tuning thing.

Anyhow, it was nice to ride around. Yeah, it’s a little big, but it’s not a big bike. There’s plenty of pep for the city. Running up HWY 30, it did fine with the lunch crowd and there was plenty of power to overtake or squeeze out of spots at urban parkway speeds. I’d do exit-to-exit on the Portland bypasses with it.

I was also glad to see an RE dealership up in St. John. Wasn’t a fan of the Harley dealership I was getting service at and had to do a lot of research on my own to get help when it was suffering from factory QA problems.

I recently recommended Mackup, a Mac config syncronization tool, but I’m having a few issues with it now. In general, it does a pretty good job with most apps, but I ran into a weird bug with Mailmate where it kept forgetting all my settings. After a few go-rounds I opened up the Console and searched for Mailmate messages and found it wasn’t able to write to its prefs file. I put Mailmate in Mackup’s skip list, removed the symlinks and let it write its files again and all was well. Searching Mackup’s issues, I found someone experiencing a similar issue with Xcode and learned it seems to be a thing with Dropbox and iCloud and certain apps. In the case of Dropbox, it has come with that app’s move to the CloudStorage folder.

I’m not sure this is enough to get me quit using it. It works quite well with my Emacs config, gpg, ssh, zsh, and other stuff. I also like using it for syncing my ~/bin. It doesn’t work so well with Terminal.app, and gets a little weird now and then with a few other things.

Just … proceed with caution, I guess is the advice. For now I’ve got Mailmate, Terminal.app, karabiner, and Bartender on the skip list. That’s fine for most of them: They’re generally best configured a little different between laptop and desktop anyhow.

My org-contacts file and Things

I stopped using mu4e. I was uncomfortable with the interplay between several different clients (both automated and user-facing) and my Maildir and IMAP. That left a a small hole in the functionality I’d built into my org-mode PRM: being able to quickly mail a contact from a Doom Emacs menu. So I made a quick function that just turns the email address in the org-contacts record into a mailto: link and open call to the system that invokes my preferred mail client (Mailmate at this point). So if the point is over an org-contacts heading I can SPC C m (“leader - CRM - mail”) and get a new message.

I’m on the record somewhere about not liking the emphasis on URL schemes for Mac automation. I don’t like the ins and outs of encoding values and cramming data into that format. At the same time, it does seem to have kept the idea of Mac end-user automation from fading away. So as I sat there looking at my new mailto function, I wondered about how all the contact data I’m keeping could interact with the wider Mac ecosystem in a sort of “if needed” manner, hence this little thing.

It just provides an interactive menu for selecting a contact activity (ping, call, write, etc.) and an interactive date picker, then makes a Thing todo that includes the tags for the contact, with a “start date.” I can get at it with SPC C g (“leader CRM thinGs”). I don’t mean to use it? I was just curious. I’m not sure.

What I am learning as I use org-mode day-to-day again is that there are things that come naturally to it and that do not come naturally to it. I’ve got working integrations with my calendar, for instance, but calendar syncing is another one of those things that eats the one thread you have to work with when it runs, and sometimes it does mysterious things if you mess with a plaintext representation of a more complex data structure that was never written with direct human interaction in mind.

That’s always the struggle with Emacs: What can it do, and what should it do?

The temptation is to crawl into a uni-environment and torture everything into some kind of alignment, but that’s brittle. It might feel good if your temperament or proclivities lead you to feeling comfortable with that particular shape, but there are tradeoffs whether you acknowledge them or not. In this particular case, the line I am sensing is the line between “getting things done” in a very mixed, tactical, “chores, obligations, and interrupts” kind of way, and getting things done in a very “life is an information problem” kind of way.

I love org-mode as a way of organizing information and thoughts. In particular, I am very fond of all the refiling capabilities it offers, because ideas and information can be shuffled around between different contexts inside the broader org-mode context without lifting a hand from the keyboard. As a day-to-day “chores and household projects” tool, I’m a little less certain about it, mainly because of the mobile piece. beorg is great, but it is also a little bit of work to use, and its syncing model is borrowed, so it’s not as good as a purpose-built solution. Further, it is not consistent with my desktop org-mode environments when it comes to things like the agenda views.

So, you know, the interesting thing to me becomes “how can this sophisticated text manipulation environment fit into a broader toolkit?” How can all these things interconnect and complement each other? What are the kinds of work that makes sense living in a purpose-built tool because their typical context favors less thinking and less complexity, vs. the kinds of work that are broadly the same thing (“a thing I need to do”) that benefit from more thinking and more complexity? What kinds of tasks can be “dead” and in a little purpose-built silo, and what kinds of tasks benefit from a little bit of added complexity to exist in a better context? How could a thing move from one environment to the other?

Interesting to me, anyhow, because my tendency, at rest – my unconscious tendency – is to want everything in one tool, but I continue to learn over time that the one-tool outlook breeds its own kinds of complexity.

Anyhow, here’s that function. It works okay so far. The one glitch is that the Things URL scheme won’t make a tag if it doesn’t exist, so I had to go in and tag an existing todo with all my contact types (friend, network, recruiter, etc.) to get the function to properly tag a contact todo.

(defun mph/org-contacts-to-things (contact-kind)
  "Create a Things to-do item based on the current Org Contacts record.
   CONTACT-KIND is a string that specifies the kind of contact ('ping', 'call', 'write', 'schedule', or 'follow up')."
  (interactive
   (list
    (completing-read "Contact Kind: " '("ping" "call" "write" "schedule" "follow up"))))
  (let* ((name (org-entry-get nil "Name"))
         (email (org-entry-get nil "Email"))
         (phone (org-entry-get nil "Phone"))
         (note (read-string "Note: "))
         (notes (format "Email: %s\nPhone: %s\nNote: %s" email phone note))
         (start-date (org-read-date nil nil nil "Start Date: "))
         (start-date-string (format-time-string "%Y-%m-%d" (org-time-string-to-time start-date)))
         (tags (org-get-tags nil t))
         (tag-string (if tags (mapconcat 'identity tags ",") ""))
         (title (format "%s: %s" contact-kind name))
         (url (format "things:///add?title=%s&notes=%s&when=%s&tags=%s"
                      (url-encode-url title) (url-encode-url notes)
                      (url-encode-url start-date-string) (url-encode-url tag-string))))
    (start-process-shell-command "open" nil (format "open \"%s\"" url))))

Conversations, not interviews

Refreshing interview closer of the month:

“We have a few minutes left, any questions of me?”

“No. I came into this thinking you’d either say ‘did you even read the job description? Now good day while I go fire the recruiter,’ or you’d see something that would lead you to want a conversation, which I hope we’ll continue so I can learn more.”

And there we were, having a conversation.

I’ve been very lucky to have had several conversations recently. It’s reminding me of the times I had interviews and how those things went wrong down the road. It’s great to end a conversation hearing the person you were conversing with say “wow, the time flew by … but this felt so organic.” You can enter a conversation with curiosity, and with a good conversational partner you can see where things go, make connections to your experience in the moment, change course or call up other experiences when they say “well, that’s not quite what we’re dealing with here.” That’s much better than pre-thinking a bunch of answers and poring over “ten most common questions” or (if Nigel or Chris are reading) “you’re trapped in a 20’ blender” scenarios.

I’ll include that below, but the other thing to link to before your eyes glaze over with a hunk of Ruby is this useful post on using consult-ripgrep with org-roam for fulltext search from the org-roam Discourse. I’ve been careful to tag everything I’ve put in so far, but I won’t get to that with this batch of files, and I usually remember a keyword, anyhow. So they’re just tagged with “quotes” and “commonplace” for now.

The script just consumes the JSON that DayOne’s export function provides and coughs out formatted org-roam nodes. It uses DayOne’s uuid’s, but tacks on a few words – just in case? Maybe over time I’ll go clean up the titles but for now they’re just there to provide a hint when I search.

#!/usr/bin/env ruby

require 'json'
require 'date'

# Set these up before running
src_json = "/path/to/file.json"
destination_dir = "/path/to/export/dir"

# Read the JSON file
json_str = File.read(src_json)

# Parse the JSON string
data = JSON.parse(json_str)

def write_json_to_org_roam_files(json_str, path)
  data = JSON.parse(json_str)
  entries = data['entries']
  entries.each do |entry|
    created_date = DateTime.parse(entry['creationDate']).strftime('%Y%m%d%H%M%S')
    title = entry['text'].gsub(/^"/, '').gsub(/"$/, '').gsub(/[^a-zA-Z0-9 ]/, ' ').squeeze(' ').strip # replace non-alphanumeric with space, remove extra spaces
    first_words = title.split.first(5).join(' ').gsub(/[^a-zA-Z0-9]/, '-') # replace non-alphanumeric with dash
    uuid = first_words + '-' + entry['uuid']
    content = JSON.parse(entry['richText'])['contents'].map { |c| c['text'] }.join("\n")
    filename = "#{created_date}-#{first_words}.org".gsub(/^-/, '').gsub(/-$/, '').gsub(/-{2,}/,'-') # remove leading/trailing dashes and collapse multiple dashes
    file_content = <<~ORG_NODE.gsub(/^\s*/, '')
      :PROPERTIES:
      :ID: #{uuid}
      :END:
      #+title: #{first_words}
      #+filetags: :commonplace:quotes:

      #{content}
    ORG_NODE
    file = File.open(File.join(path, filename), 'w')
    file.write(file_content)
    file.close
  end
end
# Iterate over each entry
data['entries'].each do |entry|
  write_json_to_org_roam_files(json_str, File.expand_path(destination_dir))
end

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

Overall, it was a land of contrasts. It did some things really well, or got to “really well” with a few followup requests. But on the other end of the spectrum it simply invented non-existent functionality then documented how to configure it.

I don’t have any particularly original takeaways. Put me in the broad camp of “human venality is going to be the real problem here,” in ways it already is where other kinds of automation are concerned. We live in a society where people not only, like, read a newspaper in their Tesla, but literally crawl into the back seat and take naps.

The trivial tasks I fed it were limited, so the errors it made were obvious. I wasn’t trying to prove or disprove its … quality? If you’ve ever gotten into an argument with a word processor’s grammar checker you’ll sort of understand what you’re up against in this case, too, with the improvement over that scenario being that instead of staring at the alleged bad grammar and ultimately learning you’re either a “leave the blue squiggles” person or a “can’t tolerate any blue squiggles” person, you can tell it you didn’t care for the answer and it often takes the hint and fixes the problem.

But you have to know that you don’t like the answer. So when it wrote a Puppet module for me and did so with insecure code, I noticed that and told it to do better and it did. Nothing got into production. When it gave me unreadable output for a train schedule, its first correction was at least obviously and intuitively wrong. Nothing got into production.

When I think about more complex code I’ve written the human dimension of the problem stands out more. I once modeled website revenue for a Rails app, which involved a lot of sorting out when data was sampled vs. when it wasn’t, recursive reasoning around costs, etc. and remember the many ways I could lose my train of thought and introduce stuff that looked right even to my experienced eye as a domain expert who knew the problem space as a practitioner and who was describing that expertise in code. No misunderstood requirements, no senior dev fighting with the product owner because reality is stupid, no UX designer arguing that beauty is truth. Just me, passionately invested in the problem, and still introducing errors I couldn’t spot on review … that I could only spot with tedious testing.

Anyhow. Nothing new.

Some of the things I tried:

Create an org capture template for daily health logging

It did the request perfectly, but slightly idiosyncratically for a log format (it stuck the date in the :DRAWER: instead of as an inactive date label in the head). Subsequent conversational-style prompts (“okay, but could you include weight and hours slept?”) caused it to add prompts for those to the template, then “could you make that information that appends to an org table instead” generated a capture template appropriate to appending to a table.

A similar request to create an org-capture template for Hugo blogging was mostly correct, but had a few glitches and the verbose instructions left out a key variable. It was debuggable in a few minutes.

I’d score it pretty highly, and using it for that task is just straightforward “get to the point of the tool, not the labor involved in the tool” utility. Mostly I appreciated that it matched all the parens correctly.

Tell me how to configure OfflineIMAP for use with mutt on a Mac

Did I say yesterday I don’t believe in that? I did. But it was on my mind.

It did this pretty well, delivering instructions tailored to the specific “mutt + offlineimap” use case that were as good as any tutorial, missing only the things that are idiosyncratic to Fastmail, which I forgot to mention to it. I should have thought to tell it I was getting the errors I got to see how it handled that. Instead I just searched for them on DuckDuckGo and got unstuck.

Interestingly, and this happened one other time, I lost the original request to a glitch in the web app. When I restated it only slightly differently … not in a way that you’d think would materially affect the output … it came up with something slightly different that didn’t leave out a key detail the original output did.

I’d score it highly again, minus maybe its willingness to make message deletion live by default without warning. Other examples and tutorials I found mention that.

I followed up by asking it to show me how to capture that configuration with Puppet and hiera, and it produced a serviceable OfflineIMAP module. It would have had me storing my credentials in the plain in the Hiera YAML. I responded that I preferred not to do that so it provided me with an example that used eyaml.

Tell me how to use mutt with a Bayesian filter

It went completely off the rails, inventing filtering functionality for mutt and offering configuration examples that looked – mutt-like? – but inventing a configuration variable that doesn’t exist, near as I can tell, to invoke a configuration file mutt wouldn’t look for to support the non-existent functionality.

Maybe the interesting thing that came out of the interaction was the way it cooked up a mutt-like filtering setup could work in a way that seemed idiomatically correct for mutt. It just did the technical equivalent of adding a sixth finger to the left hand by assuming a generic bayesian filter of some kind and taking the plumbing to connect it for granted.

How would I go about adding a second RSS feed with a different template for a hugo site?

Another miss, with very reasonable-looking instructions that simply didn’t work as proposed. I am not sure how close it actually got. That’s a problem I spent some time trying to solve yesterday and it seemed close but missed some connections between content and template.

It gave its configuration examples in TOML, and responded correctly to a conversational “could I have those examples in YAML” prompt.

Tell me how to write a Sinatra app to download an rss feed, filter it for keywords and save another version of the feed

Prompted by a Mastodon conversation yesterday about RSS readers that could be used to filter sponsored content posts.

Up front, it’s sort of a weird request on my part: I was just lazily typing in part of an idea, including Sinatra as a dependency but not explaining why (my idea would involve creating a sort of RSS proxy with dynamic filtering during each client request). I just wanted to see what it would do without putting a lot of thought into it, or sticking around to narrow things down. So I got a ruby script wrapped in a Sinatra route, honoring the request whether it made a ton of sense or not.

I’ve had it do a couple of Ruby scripts, and it remembered to include `require` lines for gems. It didn’t do that in this case. I added them and it ran. I had to tweak a few things to get it to run without error, and the filtering didn’t work.

I might goof around with this one a bit more to see where it’s going wrong.

This lined up with things I’ve read from others over the past few months: It produced a scaffold of mostly working code. If I decide to mess around with it more, I’ll have been saved digging around for examples of the basic syntax for the assorted parts of the workflow that I know from experience are correct.

“What’s a good strategy for switching between regular and ortholinear keyboards?”

Useless. It provided very reasonable instructions for how to learn how to use an ortholinear keyboard, but didn’t address the actual request.

“Tell me how to write a ruby script to download train times for a given stop in Portland oregon”

It produced working code that showed me the next arrival times for the next train at my neighborhood stop. It provided the correct link to sign up with TriMet to get an API key.

“A-” because it didn’t translate epoch time to human time in the output. When I asked it to do that, it tried to comply and used the obvious syntax to convert the integer it got back from the API, but got confused by the millisecond format.

I tried the code and replied with:

“That time format is still incorrect. I think the timestamps include miliseconds.”

It replied with:

“You’re correct, I apologize for the oversight. It appears that the TriMet API returns timestamps with milliseconds.”

Then it produced working code that did a simple operation on the timestamp and passed it along to Time and strftime with correctly formatted output.

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.

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}