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.