I like the ideas I get from taking a tour of a tool like Logseq, even if I don’t think the whole thing is going to work for me. It’s a chance to fold ideas into what is practically my forever tool, which is org-mode/Emacs, or at least rethink things I thought were more bothersome to fix than they sometimes end up being.

The last few weeks I’ve been intrigued by PARA as a simple organizing principle, I’ve wanted to continue to mesh prose and tasks in the way org-mode excels, and I’ve wanted to de-gunk my Denote setup.

I gave Logseq a try, looked at Workflowy again, and briefly dusted off my last Obsidian setup. Logseq and Obsidian are pretty good at surfacing tasks from all over your notes collection. org-mode can manage that but it is very oriented around the org agenda as a way to see your tasks, and the agenda doesn’t scale well with large collections of notes.

There are a few ways of coming at that problem, ranging from “just be selective about which files go into the agenda” to functions that pre-scan your corpus cheaply then assemble a list of agenda files only from things with active todos.

I am still a long way away from having a notes collection large enough to slow the agenda down, but it’s growing.

So, in the midst of poking around and trying to decide whether or not to add one of several possible lumps of lisp to my config, I came across Jack Baty’s post on his own solution, which is limiting your agenda files to just project files, based on Denote’s naming convention.

My own Denote hierarchy has a bunch of little atomic notes, then a collection of project files, area files, and people files. It also has a home file that indexes the project and area files, and an inbox file. I’ve been experimenting with a foundations type that I use to define core concepts. For instance, my team’s work a specific tool migration might be a project file; while portfolio management generally is an area file. Defining what even is the portfolio, what it means for someone on the team to own a piece of the portfolio, and what expectations are for portfolio owners is a piece of foundation thinking.

I can see putting tasks in those special-purpose files, and will tend to avoid putting them in tinier atomic or fragmentary notes files. Feels like a reasonable compromise that discourages littering my notes with tasks, keeps org’s agenda efficient, and provides a little bit of structure that I feel can go missing in a strictly anti-hierarchical note setup.

The code Jack shared defines denote-to-agenda-regexp to make a decision on whether or not some supporting functions should include a file in the agenda. He limits his to files with _project in the name (derived from having project somewhere in the filetags). I wanted to include area and people, too, so I expanded the regexp (inelegantly):

(defvar my-denote-to-agenda-regexp "_project\\|_area\\|_people\\|_inbox"
      "Denote file names that are added to the agenda.
    See `my-add-denote-to-agenda'.")

I’ve also added the project/area/person name as the #+category: property in my agenda-ready files, since that cleans up the far-left column on the agenda, which is the (very long in Denote) filename by default.

Forsaking mobile

I guess the other development of all the cleanup and fussing was choosing to not care about the mobile use case for this stuff at all.

I think I have shared elsewhere that one of my formative work experiences included being handed the keys to a portfolio of websites with zero supporting staff and being expected to keep comment moderation going seven days a week. I developed a small fixation around mobile work that predated useful technology for mobile work by a good number of years. It made sense because it allowed me to be out and about and doing little moderation micro-tasks whenever.

Since then, I’ve had this scar or kink or crease in my brain about making sure the mobile bases are covered, but the more I think about it the more I think it’s a bad idea. It’s bad enough that I let Slack or Gmail on my phone, let alone wanting all my work notes and tasks available wherever I am. I suppose in a truly, truly dire situation I could use Blink to sign in to the desktop machine and run an agenda or look up a note, but that’s a ridiculous scenario and the better answer is probably “yeah, sorry, away from my computer rn.”

I’m back and forth on whether to stick to org-gtd or to start using Things again. I wanted to re-tag some actions on the fly this morning and it took some extra typing I didn’t want to do. So far, my org-gtd and Denote usage haven’t intersected, and there is no way I can think of that any of the existing mobile tools could do anything for me at all if they did. So as I think about my Emacs/Denote/org estate, and how to decompose it and remix different pieces, there’s a pretty clean perforated line between written notes and tasks, provided I can find a way to bridge the two.

One thing I used to do when I was a regular Bear user was create a Things project for all the people I had regular 1:1s with. I set up section headings for each person in the project under which I dropped actions I owed or had delegated. At the top of that project, I had a list of links to my 1:1 notes with each person to make it easier to get to past notes during a meeting without looking them up in Bear – just save the URL to their 1:1 file, click the link, Bear opens to where I need it. This felt like a clean way to let two tools do what they’re best at: Things does have some basic Markdown editing, but I don’t generally want to embed writing/thinking in actions.

Unlike Bear, Emacs has the disadvantage of not being everywhere I would use Things, but since I’m exporting my Denote stuff to the web, my notes do have a permanent URL, and it’s derived from the filename of a given note, so it’s easy to convert the file path to the URL.

This function copies that URL to the clipboard when I’m in a note. No error- or sanity-checking: The results will be nonsense if I invoke it outside my Denote hierarchy, but I bound it to my Denote menu in Doom Emacs so it’ll only come up when it’s contextually appropriate:

(defun mph/convert-to-skyhook-url ()
  "Converts the current buffer's path to a URL for the Skyhook notes."
  (interactive)
  (let* ((buffer-path (buffer-file-name))
         (notes-directory "/Users/mph/org/notes/")
         (relative-path (file-relative-name buffer-path notes-directory))
         (html-path (concat (file-name-sans-extension relative-path) ".html"))
         (url-prefix "http://skyhook:8888/")
         (url (concat url-prefix html-path)))
    (kill-new url)
    (message "Skyhook URL: %s" url)))

Then it’s just dropping it into a Things project page and wrapping it in Markdown link markup.

There’s a converse linking relationship between todos and notes, and I made something to address that, too:

;; updated to de-hard-code the # symbol -- any symbol is sanitized for use in a URL now
(after! org
  (org-link-set-parameters "things"
    :follow (lambda (label) (browse-url (concat "things:///search?query=" (url-hexify-string label))))
    :export (lambda (path desc backend)
              (cond
               ((eq 'html backend)
                (format "<a href=\"things:///search?query=%s\">Things: %s</a>"
                        (url-hexify-string path)
                        (org-html-encode-plain-text path)))))))

It’s a custom org external link for Things. Enter a link of this format:

[[things:#foo]]

… and it will link to a Things search for #foo.

The :export section insures that when I publish the site, the things:// URL scheme survives. When org-mode comes across protocols it doesn’t recognize it mangles them. This ensures that things: URLs show up in the rendered HTML.

So if I’m sitting down to a 1:1 with “Joe Grudd,” I’ve got a link to the web version of his metanote from Things on a computer or phone. If I’m looking at Joe Grudd’s metanote in Emacs or on the web, I’ve got a link that shows a search for anything tagged #joeg in Things.

Automating dblock-driven metanote updates

I have metanotes set up in my Denote hierarchy for frequent people and topic tags. The metanotes are semi-automated at this point using Denote’s dynamic blocks.

#+BEGIN: denote-links :regexp "_rfc"
#+END:

Just C-c C-c in that block and it expands to something like:

#+BEGIN: denote-links :regexp "_rfc"
- [[denote:20230613T083549][RFC - Crosstraining]]
- [[denote:20230613T083700][RFC - IT Portfolio]]
- [[denote:20230613T083726][RFC - Status and progress]]
#+END:

All those Denote links are translated by org-publish during conversion to HTML, so a link to a metanote on the web server gets me to the HTML version of all the linked notes.

If I’m on a laptop, getting to the metanotes is pretty easy: They’re all in a metanote at the top of my Denote hierarchy, so that’s easy enough to get to in “full computer” contexts.

The biggest hole in this workflow is that that dynamic blocks have to be updated. I semi-automated it yesterday with a save hook in my Denote directory that updates any dblocks in a file before it saves, but you have to be in a metanote for that to happen.

Not sure if there’s a more efficient way to do it, but this automates the update process:

(defun mph/update-meta-dblocks (directory)
  "Update dynamic blocks, save, and publish HTML for files with '_meta' in the name in the given DIRECTORY."
  (interactive "DSelect directory: ")
  (let ((files (directory-files directory nil "\\.org$")))
    (dolist (file files)
      (when (string-match-p "_meta" file)
        (let ((org-file (concat directory "/" file)))
          (with-current-buffer (find-file-noselect org-file)
            ;; Suspend hooks temporarily
            (run-hooks 'no-hooks)
            (org-update-all-dblocks)
            (save-buffer)
            ))))))

(The run-hooks 'no-hooks business is there to keep my post-save publishing hooks from running with each touch, which I think will make this safe to use as a pre-processing hook.) I think I’m going to just use it as I remember it for a few days until I can see how much time it chews up. Maybe it’s better run as a scheduled batch thing now and then.

Cleaning up org publishing exports

I also took the time to clean up HTML publishing last night. Emacs documentation ftw: I used the publishing options page to run down settings/variables and what they do. In particular:

org-html-divs

I use SimpleCSS to save a few steps. org-html-divs lets you set the preamble, content, and postamble element types and id’s, so:

(setq org-html-divs
    '((preamble "header" "preamble") ;; set the preamble div to a <header> element with an id of "preamble"
      (content "main" "content") ;; etc.
      (postamble "footer" "postamble")))
(setq org-export-with-author nil)

I kept the id’s so I could have a reference for debugging and keep sight of org’s nomenclature.

org-html-preamble

To get a SimpleCSS nav into place, markup has to go into the export’s preamble:

(setq org-html-preamble "<nav><ul>
                           <li><a href=\"/\" class=\"home\">Home</a>
                           <li><a href=\"/sitemap.html\">All Notes</a>
                           </ul>
                         </nav>
                         ")

org-html-head

To pull in SimpleCSS, FuseJS, and a local style sheet:

(setq
      org-html-head "<link rel=\"stylesheet\" href=\"https://cdn.simplecss.org/simple.min.css\" />
                     <link rel=\"stylesheet\" href=\"/local.css\" />
                     <script src=\"https://cdn.jsdelivr.net/npm/fuse.js@6.6.2\"></script>")

espanso

I don’t know what on Earth happened to TextExpander but wow it isn’t good.

Looking around for a text expansion tool of some kind I came across espanso. It’s a snippet tool. It behaves about like yasnippet or TextMate snippets: Start typing a trigger phrase and it expands it for you.

Most of these things are wrapped in a GUI. espanso is configurable with a YAML file. It also has some cool stuff for handling regexps that allow you to use variables to your snippets. For instance:

- regex: ":tml\\((?P<tag>.*)\\)"
  replace: "[Items tagged `{{tag}}` in Things](things:///search?query=%23{{tag}})"

If you type :tml(foo) it’ll expand to a Markdown link using foo.

[Items tagged `foo` in Things](things:///search?query=%23foo)

(I’m not sure, btw, how to do that in yasnippet and need to figure that out.)

I’ve been back and forth on bookmarking. For a period there was some noise about pinboard.in appearing moribund. The obvious explanation for some of the noise generally was that Maciej Cegłowski’s smartest guy in the room schtick had finally run afoul of peoples’ sensibilities. The one supporting piece of evidence I had in my own experience was an unanswered bug report about broken feed functionality.

So I tried raindrop.io (didn’t really take), and then just stopped bookmarking stuff because I wasn’t sure where to put it, and then started playing around with beorg to capture bookmarks on mobile, which worked fine but I hadn’t yet figured out a way to make the practice scale.

Well, the bug I reported about pinboard got fixed, Maciej seems to be active online again, and pinboard is my favorite service, so I’m using it. For mobile I like the Pins app a lot. It’s just clean and simple, and it’s a universal app so its share extension works on my Macs in apps like Reeder.

Since I’ve moved blogging into Emacs, it’d be nice to be able to get links I save out of pinboard and into a buffer, and it looks like Dave Pearson’s pinboard.el will suffice. It provides a pinboard client in Emacs: invoke it, get a list of your bookmarks, do things with them. Konrad Hensen wrote a function that can store a pinboard.el link as an org link.

Blogging and org

I added ox-hugo to my blogging toolkit as an experiment in blogging with org-mode. You just add a section to a monolithic file, compose with org markup, and save. ox-hugo exports the content to a well-formed Hugo Markdown file. Used in conjunction with Hugo server’s --navigateToChanged switch, realtime feedback is easy.

Some things I like about it:

• Adding TODO to the front of the heading makes the post a draft.
• Normal org tags at the end of the heading, e.g. :emacs:gtd:blogging: become tags for the post.
• Participation in the org ecosystem, e.g. being able to use org-refile on stuff that’s not quite ready for today’s edition.

I’m not so sure about it as a longterm document pipeline. This isn’t a workflow amenable to anything other than a normal computer that can properly run Emacs. That’s not a big deal right now: My iPad is pretty strictly for content consumption these days. But when I think about camping season arriving and how much better suited to that an iPad is, I have qualms. I have no problem imagining an iPad-centric Hugo workflow using any of a number of tools, especially given my publishing pipeline. I don’t like the idea of dragging a laptop along.

I get the feeling this is going to land in the “fun but not for me” pile.

On the other hand, I’ve got Tailscale running and there’s Blink. I can always get to something that can run Emacs that way. If I’m on the grid enough to blog, I’m on the grid enough to mosh into something and push out a post.

It’s worth a little thinking because the more I do with org mode the more I realize it’s how I’d prefer to author stuff of any complexity, or stuff that could become part of something more complex at some point.

Hoping Yellowjackets won’t disappoint

Al and I have been watching the first season. We’ve arrived in the traditional part of a ten-episode season, where things begin to bog down a little and I’m hoping it will get a little more sprightly again. And I’m going through my usual qualms about shows that look and act like this one: I don’t mind some mystery, but I have lost my tolerance for series that won’t resolve anything. If it looks like it’s going to be an endless puzzlebox, it’s not going to get my time.

The ten episode thing: I wish I knew some television writers who could walk me through the realities of doing an eight-, ten-, twelve-, or twenty-episode season.

Sharp Objects, Mare of Easttown and Severance all came in at seven or eight episodes, and they felt just right to me. Things stayed tight and they kept moving. For All Mankind comes in at ten per season, and sometimes it drags. The Wire ran 12 or 13 episodes per season (except the last), and I’d say it could have tightened down, too.

You just hit those moments, I suppose, where all the setup is done, the Big Problem for the season is established, and … wham, into a bottle episode or a dream episode that feels loosely connected – or a subplot goes on unresolved for a few episodes – and you feel the momentum seeping out.

I suppose there are some economics around the first run and eventual syndication, and probably increasingly good metrics around what audiences will stick with in what numbers. I just wonder what about the structure (at the episode level and the season level) makes things seem to get a little pokey at ten episodes. I took a writing for film class years ago where the person who did the screenplay for Erin Brokovich sat with the class and walked us through the structure, and I’ve read since that these things follow predictable patterns you mainly notice when they’re broken. I can see how perhaps writers learn a certain tempo within a certain framework and end up with more time than they know what to do with.

And maybe it’s just me being affected by streaming and binge-watching. I’m still generally on team “3 hours for a movie? Sounds like a good deal!” so I don’t think my attention span has been completely ruined, but there’s just so much out there – maybe I’ve been conditioned by the bounty that is Peak Television to look ahead to the next thing in a way I have not by movies.

Anyhow: We are enjoying it for now. The cast is solid, the timeline switching keeps things moving, and showing us the fate of one of the main characters in the first scene of the first episode seems to have worked, though I get the feeling something will happen along the way to complicate that.