It doesn’t toss you into the plaintext-n-filesystem primitivist deep end on your own. It comes with a dired mode that fontifies based on its own filenaming convention, so what seems like it could be super ungainly is actually pretty easy to scan in practice:

… and it has a collection of functions that let you add/remove keywords, rename files using its naming convention, etc. There are even a few next-level sorts of things, such as the ability to create content “silos,” so you can set up a note directory for personal stuff, work stuff, etc. without clashing label namespaces and other things that come up when you have to manage a few discrete areas with the same tool.

As “what would my exit plan be” tools go, this one is pretty good, given It’s All Just Text with no particularly difficult conventions.

It was trivial to move a bunch of notes into a directory, use Denote’s built-in tools to convert them to the proper naming convention, and start using it. It took under a minute to convert a function I cribbed from org-roam’s forums to use ripgrep to provide fulltext search:

(defun mph/denote-rg-search ()
  "Search denote directory using consult-ripgrep. With live-preview."
  (interactive)
  (let ((consult-ripgrep-command "rg --null --smart-case --type org --line-buffered --color=always --max-columns=500 --no-heading --line-number . -e ARG OPTS"))
    (consult-ripgrep denote-directory)))

(map! :leader
      (:prefix-map ("n" . "notes")
      (:prefix ("D" . "Denote")
       :desc "ripgrep" "/" #'mph/denote-rg-search)))

The obvious comparisons in the Emacs ecosystem are Deft and org-roam. I haven’t given Deft much time. I’ve used org-roam more. I like Denote’s lack of a dependency on a database. I don’t know how Denote will compare in terms of scale if it’s all filesystem-and-native-tools.

So, org-gtd makes heavy use of org-edna:

When you’re working down a project’s todos, each time one flips to DONE it triggers org-edna to move the next task into a NEXT state. So far so good and awesome if you’re just using Emacs.

If you’re out and about with your iPhone (or Orgzly, or whatever) and do not have a full Emacs environment, any state changes to a todo item won’t have org-edna there to monitor and make the needed state changes for the next item.

Today, for instance, I am going to be out and about running a few errands that include picking some things up that I need to complete a few projects. I have a custom view set up in BeOrg to show me my @errands items in NEXT state. When I stop by the motorcycle shop to pick up a battery for my Grom, I’ll want to tick that errand off as DONE. Because org-edna isn’t there, the next item in the “Get the Grom ready for summer” project won’t flip into a NEXT state, and org-gtd’s handy “next actions” agenda list will lose track of the project (unless I explicitly check for stuck projects – projects with no item in a NEXT state.)

David Masterson on the BeOrg user forum was grappling with the same problem and suggested a pretty good idea: Adding a transitional TODO state to BeOrg that you’d then manually flip to DONE once sitting in front of Emacs on a real computer. That’d then trigger org-edna and your list automation would be back on track. He proposed PRE-DONE, I just went with BEDONE:

(defun mph/org-change-bedone-to-done ()
  "Change all 'BEDONE' states to 'DONE' in current buffer."
  (interactive)
  (save-excursion
    (goto-char (point-min))
    (while (re-search-forward org-heading-regexp nil t)
      (when (string= (org-get-todo-state) "BEDONE")
        (org-todo "DONE")))))

Then you’d just want to automate that:

(add-hook 'org-mode-hook 'mph/org-change-bedone-to-done)

The two additional bits of setup: Adding “BEDONE” to BeOrg’s list of todo states, and making sure it is also in the TODO state list in your Emacs config, or in the file you’re going to operate on. If you just try to use “BEDONE” instead of “DONE” without blessing it as an actual TODO state, the function will treat it like arbitrary text and ignore it.

My Grom example is pretty simplistic: I’m not going to forget I am trying to get the Grom ready for summer, and will eventually go looking for the rest of the project if I accidentally move it into a stuck, next-actionless state. But the whole point of org-gtd – GTD generally – is that you want to remove as much “holding stuff in your head” as possible.

The limits of hyper-automated plaintext primtivism

For the record, yes, this is pushing things. All sorts of things. The limits of hyper-automated plaintext primitivism. The willful naivete of GTD as a method. My own laziness, because the other option is to just write this stuff down and stick it in my pocket on the way out the door, or to not use BeOrg interactively if I’m going to have a bunch of desktop-only automation.

The only real defense I have right now is, “it’s fun.”

The only way to keep having this kind of fun will eventually be to either become a primitivist hyper-automation plaintext fetishism influencer with no need to do things like “direct corporate IT operations” or “lead product engineering groups;” or to crowd out other things in my life that matter much, much more than relieving myself of the drudgery of manually changing TODO states in a plaintext file.

A friend asked, “are you ready to go back?”

Yeah … seven months in, three of which were very deliberate rest, the rest of which have involved a state of relaxed calm but the stochastic cadence of screenings, interviews, and panels … I am ready: Rested, as clear on my purpose in the workplace as I have been in a long time, and as clear on what I am getting for my time as I have ever been. Uncle Tupelo for the rest.

Years ago I came across a curious point of view about how to set up a Mac called “The Good Easy.” It would be completely unacceptable to anyone I know working in tech, not because of its underlying principles, which are interesting, but because it presumes that it’s okay to tell a new hire “this is how you will use your computer.” No, not “this is how our team works together, figure out how to interface with it with your preferred toolkit,” but “do these exact things to your computer:”

Stuff like:

… in BBEdit, make sure it’s set to softwrap, window width, start up with nothing, searches wrap around, don’t print headers or date stamp, don’t show any toolbars and make veggie the default font.

and

… keyboard control panel make the repeat rate as fast as possible and the delay as short as possible. Under options, assign f keys (7 netscape, 8 emailer, 9 bbedit, 10 now up to date)

and

… trash should be viewed as a list

I think it burbled into my view during The Great Lifehack Explosion of the early aughts when WIRED did a little writeup, and I’d guess it sparked interest because it was an OS9-era attempt to steer the Mac experience toward something more plaintext and keyboard-centric than was considered “normal” to people at the turn of the century. A Mac wasn’t a thing, at that point, with a BSD userland or thousands of classic UNIX apps all tuned toward processing text.

Anyhow, as I think about my note-taking and what things belong where in it, I think about that particular period in nerd culture: UNIX primitivists had Linux, but it was a hard thing to love when the answer to having both a working printer and the ability to burn CDs, and a working sound card was probably one custom kernel build to put the missing thing in, another custom build to put the thing back in you forget was “just working” for a reason, and maybe a third build just because you didn’t follow the recipe.

OS X was interesting because you could listen to music, burn CDs, and send things to your printer without thinking about it too hard. (Well, for some reason printing to shared printers on early OS X didn’t work well when I had WEP enabled on my 802.11b network.) But there was also that interesting layer underneath … plaintext land.

Superkey

Yesterday I wrote a little about Charmstone, a task switching alternative by Ryan Hanson, who makes a lot of interesting little UI enhancers with a focus that’s a little on keyboard centricity but also just generally reducing motion. He also makes Superkey, which is adjacent to things like Vimium, which try to bring the “stay on the home row as much as possible” paradigm to the UI beyond your text editor. I’ve been using Vimari, a Vimium port for Safari; and also Homerow, which does the same thing for the entire Mac UI: Decorates every link or UI element with a tag of one or two letters you can type to jump to a given element without using a mouse.

Superkey is the same idea: You have a screen full of menus, links, and buttons and you’d rather not take your hands off the keyboard to get around, so you tap a hotkey (I mapped it to my right option key) and get a search field. Unlike Vimium et all, it doesn’t label all the UI elements, but rather begins to select the names of things as you type them. You can use the tab or semicolon key to go to the next match. Once you’re on the element you want to be on, you tap return to activate it.

The drawback of this approach compared to Vimium or other UI labeling solutions is that you probably have to type more. The advantage is that the UI isn’t completely covered with labels. For instance, here’s the front page of reddit with Vimari’s find mode activated:

On the other hand, here’s Superkey (searching for “hledger.”)

On a less cluttered page, the difference isn’t huge. On a page like reddit, with a ton of little controls masquerading as “links” all crowded in around each other, the “label everything, let the user sort it out” is pretty disorienting and sometimes simply gets in the way: Do I want va or vz? I can’t always tell.

Maybe more interesting (but I’m nowhere near using it enough at this point to know if it’s a good idea) is the possibility with Superkey that I could use it for things besides alighting on a UI control of some kind:

Ryan Gosling and the “baseline” scene in Bladerunner 2049

I really loved this deep read of Bladerunner 2049 and the baseline scene, and how Ryan Gosling brought an acting exercise to his characterization of K.

The point of the baseline test is not to fail inhumans. The culture has already decided that K is subhuman. The baseline is testing to see if someone marked as inhuman is becoming human. The baseline text, like the questions, has heavy emotional content. The environment of the baseline test is designed to maximize stress; alone in a cold white cell, the interrogator harshly barking the questions, the testee unsettled by the alien noises and unblinking eye of the monitoring equipment. It would be nearly impossible to be in that environment and not have an emotional response. But the culture has decided that replicants do not have emotional responses. The state wants dispassionate murderers for its executioners, the economy demands uncomplaining workers. The perceived emotional shortcomings of the replicants have become part of their assigned social function. So a replicant which responds to circumstances like a human is declared defective and destroyed. The culture does not even think of it as a punishment. A part is malfunctioning and it gets replaced.

Some really good thoughts about how Ridley Scott’s Bladerunner understood and misunderstood Philip K. Dick’s preoccupations, and how Villeneuve brings the story back to the source.

Made me want to go back and rewatch both, and re-read the source material, which is a mark of engaging criticism.

The downfall of Brydge

I was a relatively early Brydge customer, and felt there was no way the reviewers who had early units were being thorough. The keyboards were mushy and missed keystrokes because something was wrong with the Bluetooth, and they were physically uncomfortable devices to use when transitioning from keyboard to touch.

So I don’t feel surprised to read that they’re done. I wouldn’t have even before Apple decided to get into the “make an iPad a quasi-laptop” game for itself.

I’m not sure why I’m linking to this, except to say Brydge always felt to me like it was emblematic of a sort of superficiality in tech product reviews. It looked cool, and for a certain kind of gadget person it was a potential solution to a thing mostly Gadget People want, which is some Grand Unified Device That Does It All With No Tradeoffs. But end user reviews were not good. The Verge’s 7/10 review was inexplicable to me, especially since it missed things others were complaining about, and because one of its dings was merely that Apple had a competing product coming out.

I also looked at Monica, an open source PRM. The promising part of Monica is its API. The web UI itself shows comprehensive data for each contact, but does not do anything in the way of bulk editing and has no automation at all. It’s laborious to bootstrap.

In the process of trying to figure out how I could write some automation to move Contacts information beyond the basic vCard fields into Monica I did end up having to learn about how macOS Contacts work and realized you can create custom labels for date fields then add them to your card editing template in Contacts’ preferences.

The data entry widget for these fields expects a date and is tolerant of not entering a year (which helps it support, er, “polite” birthdays). You can, in turn, use it somewhat opaquely in a Contacts smart list: There’s a generic “Date” field you can filter on that looks at date fields in the card. Paired with a “within/not within,” or “in the next” parameter, you can make a smart list of “people not contacted in the past 30 days,” etc.

If Contacts smart lists could also use groups, you could do a lot by just setting a “last contacted” date field and making a set of smart lists based on group membership. Contacts smart lists can’t use groups, though, which is a strange oversight.

As I was trying to figure out, though, how to get my contacts uploaded to Monica in a way that would let me use its API to add tags to them once they were imported, I worked out some AppleScript that let me prepend a contact’s group into its note as a hashtag. Contacts smart lists can filter on the contents of notes.

As a solution goes, it’s in the category of “cheap and cheerful.” If you wanted to use macOS Contacts to keep track of your most recent touchpoint with someone, and drive a little automation to surface contacts you haven’t reached out to in a while, you could do it with one custom field and adopting a simple convention for notes. You’re also well into the territory of things AppleScript can do to help out, too: It is trivial to write scripts that automate logging, etc. or even write reminders or make events in a contacts calendar. In fact, here’s a script that operates on the selected contact and lets you log activity in its note:

set theDate to current date
set noteDate to do shell script "date '+%Y-%m-%d'"
tell application "Contacts"
	set selectedPeople to selection
	repeat with thePerson in selectedPeople
		set customDates to custom dates of thePerson
		set lastContactedExists to false
		repeat with aCustomDate in customDates
			if label of aCustomDate is "last contacted" then
				set value of aCustomDate to theDate
				set lastContactedExists to true
			end if
		end repeat
		if not lastContactedExists then
			if length of customDates > 0 then
				set firstCustomDate to first item of customDates
				set newCustomDate to make new custom date at after firstCustomDate
			else
				make new custom date at end of custom dates of thePerson with properties {label:"last contacted", value:theDate}
			end if
		end if
		set theNote to note of thePerson as string
		if theNote is "missing value" then set theNote to ""
		set prependText to text returned of (display dialog "Enter text to prepend to the note of " & name of thePerson & ":" default answer "" buttons {"Cancel", "OK"} default button "OK" cancel button "Cancel")
		set noteUpdated to "[" & noteDate & "] " & prependText
		if theNote is not "" then set noteUpdated to noteUpdated & return & theNote & return & " " & return
		set note of thePerson to noteUpdated
		save thePerson
	end repeat
end tell

So, looking at that, would you want to glue all this together with Applescript?

I don’t think so. I don’t, anyhow. It just took me a morning to figure that out.

In the process of roughing out automation for creating reminders, for instance, I managed to get Reminders.app to beachball on every run with a simple five-liner. Why? I don’t know. Stack Overflow didn’t know. But after a good 15 years of using AppleScript for jobs large and small, I know that sometimes you find its weird little corner cases and that’s all there is to it. I’d rather tell Jamie Zawinski that I don’t know who the author of XScreensaver is than ask Apple to fix it.

When I ask myself “would I want to build something on top of this ecosystem that I mean to use forever?” I can’t even figure out three scripts I would need to write then get to the end of debugging the second one before I know the answer is “no.”

I mean, what does forever mean? Because my personal belief is that we have to assess the foreverness of the competing candidates, and probably think about how amenable data kept in the least forever of those formats is to being migrated to a more forever format/system:

• macOS Contacts
• org-mode
• vCard
• plain text with moderately elaborate markup amenable to some automated processing

(I put that list in ascending order of longevity/permanence, feeling very appreciative that org-mode allowed me to reorder it with opt arrow).

I trust macOS Contacts a bit. I don’t how much money I would be willing to risk on a series of bets about it working as it does today in 2, 5, or 10 years. While trying to understand my AppleScript options with it I was brought face-to-face with changes to the underlying scripting model several times. In all fairness, those changes played out over decades and it’s only because I’m at a point in life where I can still think “OS X is new” that they even seem mentionable. It’s also completely possible to get Contacts info out into some other format. There’s also just the whole “ramming your head against AppleScript” aspect of the problem.

Moving up the Pyramid of Forever, I trust org-mode to be around for a very long time, but can also see how the API is still subject to change. Functions come and go so automation can break and make it hard to keep a contacts list maintained. On the other hand, I’m not doing much now that couldn’t be done by hand until I figured it out, and the things I’ve bumped into are pretty small so far: changes in the namespace, functional replacements, etc.

Moving on:

I trust the vCard standard to stay how it is a bit more. It’s on … version 3 or 4? … of the spec? There’s a spec. There are a lot of stakeholders interested in that spec. Even Apple quietly crams a whole vCard property into each contact, even if it has its own version of each property you’d find in a vCard anyhow.

So, moving on to the top of the pyramid:

I trust structured plain text to be useful for the rest of my life.

So something built on org-mode seems like the smart play for data longevity? Even if all my automation broke, core org-mode makes it easy to do the things I do: change todo states, add values to the PROPERTIES drawer, add tags, log changes, etc.

The one thing that I’ve mostly decided not to worry about is the disconnect between my contacts list and my org-contacts file.

One useful feature of contacts via Fastmail is the dynamic “Autosaved” group. If I write someone, they go into that group. Periodically moving contacts that surface there into one of my permanent groups then removing them from “Autosaved” provides a simple, organic workflow for keeping up with new people. There is also a bunch of useful automation present in macOS/iOS for surfacing things about contacts from other apps, so you’re constantly being offered the opportunity to pull in new information. This morning, for instance, going through my Contacts list, I noticed that something somewhere in the bowels of macOS or iOS was beginning to notice connections between my contacts and Ivory, the Mastodon client. That’s pretty cool.

On the other hand, this is well within AppleScript’s wheelhouse:

tell application "Contacts"
	set selectedContacts to selection
	if length of selectedContacts is not 1 then
		display alert "Please select exactly one contact."
		return
	end if

	set theContact to first item of selectedContacts

	set theName to name of theContact as text
	set theEmails to value of emails of theContact as text
	set thePhones to value of phones of theContact as text
	set theNote to note of theContact as text

	-- Format the contact data as an org contacts string
	set theContactString to "** " & theName & "
:PROPERTIES:
:EMAIL: " & theEmails & "
:PHONE: " & thePhones & "
:NOTE: " & theNote & "
:NAME: " & theName & "
:END:"

	-- Copy the contact string to the clipboard
	set the clipboard to theContactString
end tell

“Look through new contacts, run that script from a keyboard shortcut, paste the new contact into my contacts.org file.”

I could go one step further and append the text to my contacts.org file, but I don’t like operating on busy files like that.

AppleScript was plainly built to do little things like that. You have to learn its sort of crabbed, verbose way of doing things, but it’s not too hard (and Shortcuts is getting pretty good if you can deal with the sudden drop in functionality that can appear out of nowhere when you hit the limits of some Apple engineer’s imagination or time).

Anyhow, it all just comes down to aesthetics and preferences, right?

I’ve got a draft heading sitting in my blog.org file with a title of “Plain text is calming.” I’m not sure where that little essay is going, but I know where it started: When I’m staring at a text editor I feel much better than when I’m staring at a web or app UI. I might have some challenges with discoverability, or a lack of forgiveness for little slips of the finger, or whatever. But I still feel better because I’ve been a happy citizen of Plaintext Land for over 30 years, and there is a governing mentality there that does not exist in other parts of the technology world. I’m not saying the occasional wheel doesn’t get reinvented, but I am saying that with most plaintext stuff you get to choose your tools, or make them for yourself if there are no good choices. So it’s calming because I don’t have that feeling of always looking for the exit when I encounter a plaintext system. I know it’s there. That’s the preference, anyhow. I made money for a few years being really, really good at turning CMS databases into plaintext and massaging them into other CMSes, so my patience for finding the structure and working with it is high. I don’t worry about where the exit is because in my 40-year history with computers, it has never eluded me in the plaintext world.

The aesthetics are another kettle of fish, and plaintext people run a weird gamut from “text editors are like samurai swords” to “mastery of a plaintext interface is a kind of performance art.” Right now I’m sort of luxuriating in Evil mode, because I finally get the emphasis on ruthless elimination of motion vi engenders. I’ve made terrible fun of people over this in the distant past and feel a little bad about that, but less than two months into this particular experiment, I don’t want to go back. Evil mode is like the end of the first Star Trek movie as far as I’m concerned.

Anyhow, I do want to get back to the whole “plaintext is calming” idea and do some more writing about it. Today’s jaunt into “what if I could make what I wanted in the macOS ecosystem?” was one of those processes I go through when I’ve gone so far with an idea and wonder if I really want to commit – if I’m not making life a little harder on myself than I need to, or if there’s not some simpler way to do it (even if still in the DIY mode,) and the answer came back “don’t think there is.” I’m at home in what I made.

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.