A Vim and GTD Workflow

I am a major fan and daily user of Trello. However, there are some
cases where you want your GTD lists to be version controlled in
something like Git. Here’s one idea that uses Vim to do the work.

Technical Preamble

Okay, to be fair up front, I’m a Vim user. For those of you that prefer Emacs
or something else entirely this will probably still work for you. You will
just have to replace the Vim commands that I refer to with an equivalent for
the editor of your choice - if it has the feature.

To start with the nitty-gritty… The main Vim command/feature that I will use
is gf which opens the filename under the curser. Relative paths are first
searched from the location of the current buffer path.

The next but more optional feature is some way to create new files. In my
current Vim setup the gf command will not create a file because its sole
purpose is to search Vim’s path variable for a file at that relative path.

I use the NERDTree Vim Plugin so I can create a file by opening the
NERDTree with <F5> - the button that I have it configured to - and then
navigating to the target location and pressing m a. The m command
opens the file manipulation menu and the a choose the option to add a new
file. Then you just type the filename and hit enter and the plugin basically
just runs touch <target> to create an empty file on the filesystem.

Another perfectly viable option for creating the file is to use :e
<filename> or even :sh then creating the file using the bash touch
command. Whatever works best for your workflow.

That’s all of the advanced features that will be needed from your editor.
I’ll try and keep the GTD description free-ish of editor specific verbage.

GTD Description

I’m sure that I’m not the first person to describe a scheme like this. It
isn’t exactly a patentable idea either. "Do GTD in files on a filesystem" is
just another "Do this on platform foo" title which is silly and pointless.

I find this useful to use at work because the Trello site is blocked by The
Great EMC Firewall. So instead I use this scheme to track what I’m doing and
help me prepare SCRUM status updates.

To get to the meat of the topic however, the scheme in basic terms goes: Files
represent tasks, or cards in Trello. Subdirectories represent states, or
lists in Trello. Thats it.

To add some seasoning to the recipe, I add an overview file and a bash script
to help keep the overview file up to date. I’ll probably add to the script as
I decide to automate more of the process.

The worflow is so simple, and familiar to GTD’ers that I almost feel silly
summarizing it here. Again, none of this was really an original idea.

Most of the workflow description is done by running editor commands while
editing the overview RST file. First you add a new task that needs to be done
at some point in the future. Here I would create a file like "fold_laundry"
in a subdirectory called "backlog" or maybe "this_week". Note, I like to avoid
spaces and capitals so it is easier to type the paths. Then to the overview
file I add a link like `<this_week/fold_laundry>`_

Then using the open file command you can jump to the fold_laundry file and
add some text or even links to things like youtube vidoes explaining how to
fold laundry.

Later after you’ve folded the laundry you can move the file to the done
directory, or if you are adventurous you could even delete the file. Don’t
forget to update/remove the link in the overview file too.

Since our office runs a webserver with public HTML directories in each
person’s home directory I’ve also added the following cronjob command to
generate a web version of the overview page and keep things up to date:

And that’s all there is to it. The resulting web page has hyperlinks to the
plain txt files.

You can add a more complicated crontab that does something
like remove all HTML files from status dir, run find command to get all rst
files, run all rst files through rst2html.py, copy the results to the html
folder. However, you would also need to add the .html suffix to the links
in the overview file which might break the open file command. To go further
down the rabbit hole you could then write some Vim script or Emacs Lisp to
create a macro that strips the .html suffix before calling the open file
command with the string. … but who has that much energy.

That’s all for now folks. Maybe later I’ll go over the script that I wrote to
help keep the overview file up to date.