I love plain text and markdown. Scott Nesbitt’s The Plain Text Project is one of my favourite blogs, and I’ve previously written about writing a thesis in Markdown myself. One day, through The Plain Text Project, I discovered this post by Dan Lucraft around his Plain Text Personal Organizer. I instantly clicked with the idea and couldn’t wait to try it out. The purpose of this blog post is to outline my variation on Dan’s Plain Text Organiser, and how I use it to manage my life.
For those who haven’t, or won’t, read the post (you should, it’s great); Dan outlines some of the drawbacks of the “One Big Text File” (OBTF) methodology which had sprung up from a series of blogs around 2005. The idea behind this method was to keep all of one’s personal data, project management, etc in a single large text file. I was only 14 back in 2005, but in 2020 I had discovered some of these old blog posts and had even been enticed a little by the infamous GNU Emacs org-mode to cater to my project management needs. I was about ready to take the leap. Dan lists the drawbacks as: the fact that the text file must be synced religiously; the file can get very large even only using plain text; and things can get lost and difficult to find even with decent search. His iteration on the OBTF was to reconceptualise it as a digital “personal organizer” through changing the OBTF to multiple files with a directory structure, and also adding version control to keep everything in sync.
Rather splendid eh? Dan outlines his organiser’s structure in his post. He has sections built around the Getting Things Done methodology (the famous “inbox”), and has folders containing what he calls “stacks” which are lists that remain constant in size, and so forth. Seriously go read the post. I was enamoured and my brain instantly started fantasising about my own plain text folder which had to hand everything that I needed for my everyday life.
But I’m not Dan. My needs are different, my work is different, and my brain is different. So it needed adapting for my use. I was already a devout user of todo.txt, and was starting to toy with the idea of getting some form of plain text scratchpad to capture all the snippets of thoughts and tasks that I needed to jot down instantly.
So, on 2020-12-02 (a Wednesday), I ended up making my first commit in the folder that would become what I call my plain text planner. The rest of this post continues with the details of its contents and how I use it as the system as evolved over 2021 and into 2022.
Table of Contents
My folder structure
Here is the folder structure of my planner. The planner folder itself sits as ~/planner on every machine, and I have a bash shortcut p that automatically changes directory to this from wherever I am in the file system.
/planner
* scratchpad.md
* projects.md
* checklists/
* monthly.md
* weekly.md
* logs/
* [log files].txt
* todo/
* backlog.txt
* done.txt
* someday.txt
* todo.txt
* workbooks/
* [workbook files].md
As you can see, I’ve deviated from Dan’s organiser structure quite a lot based on my needs. I’ll go through each key feature now.
The Scratchpad
scratchpad.md is perhaps the most important file on my computer.
I first discovered the concept of a scratchpad via The Plain Text Project blog post. I’d previously seen, and even used, paper versions throughout my early PhD career but I’d always lose notes or forget to cross things off. I also never knew that they were called ‘scratchpads’.
For those unfamiliar with the term, a scratchpad is a pad of paper (or a digital file!) where you can quickly ‘scratch’ a thought or idea as it occurs if you’re not in a position to spend some time on the idea. After reading Scott’s article on scratchpads I was instantly taken with the idea and had even began keeping scratchpad file on my desktop. It was a no-brainer to migrate it into the planner.
The scratcpad.md file is arguably the file that changes the most in the entire planner, and sees the most heavy-duty use. I use it for everything. I don’t follow a pure Gettings Things Done productivity system; but a core concept I took from that was the idea of an inbox for capturing eveything that occurred. Now, as you’ll see later: a lot of the time I can just quickly add something to my todo.txt file. But sometimes I’m in a meeting and can’t, or the item is quite loosely defined and not actionable. It goes into the scratchpad to be handled properly later.
Another thing that the scratchpad file excels at is drafting emails. At Open Data Services Co-operative, both ourselves and our clients use some CRM ticketing systems to manage work and email external partners. These support markdown, but use a plain text entry input which means writing longer updates can be tiresome: there’s no syntax highlighting and no nice autocomplete features. This, coupled with the fact that I often think by writing and re-drafting constantly, means that I’ve found the scratchpad incredibly useful to have open as a place to quickly draft a markdown email or update before pasting it into the web.
This concept extends even further: I often need to eyeball some JSON data, and it’s often been minified for sending across the web. In these cases, I paste it into the scratchpad and make use of my text-editor to manipulate the data: tidying it, and adding syntax highlighting to help me read it.
I also use the scratchpad for some smaller computing tasks. It acts as an extended clipboard for when I need to do data entry and paste various things around different systems. It’s particularly useful for pasting thing off of the web, as it strips the formatting. I need to work with Google apps for work and it’s often much easier to paste into the scratchpad and copy back out of it than to paste some things between GDocs and GSheets (even accounting for the paste-without-formatting command). When I’m reading or writing Esperanto I also use it to note down any words I needed to look up so that I can add them to my phone’s Anki deck later. I also add reminders or notes to myself in the scratchpad that don’t quite fit anywhere else; or as a memory prompt.
The scratchpad.md file is really my main workhorse. It’s constantly open and getting filled, emptied, copied into, and copied from. Because I see it every day, I also keep a quote from my late father at the top of the file. In this sense it really becomes a replacement for a beautiful, messy, deeply personal, notebook. One that can be tidied and ‘reset’ multiple times a day without actually losing anything. Most days, I’ll clear out draft emails etc as and when they’re done, but sometimes notes can build up over a few busy days if I’ve got meetings or such.
The projects file, and Workbooks
The projects.md file, the workbooks/ folder, and the relationship between them evolved gradually. It was initially adapted from Dan’s post and how he treats his projects folder. He says:
Each file in this directory contains my notes about a project. A project must be fairly involved to get in here, otherwise I just keep a small set of notes in stacks/projects.
I loved the idea of creating a dedicated space for each major project area, while retaining a small handful of notes for smaller projects in a single space to prevent a cluttered folder. Dan has a single file for keeping notes on “open” projects, as well as “backburner” projects. My system doesn’t really make this distinction, as I’m usually painfully aware of which projects are open at a given moment.
In my system, projects.md is for collecting any and all notes on small projects. These are projects in the GTG-sense, in that they are semantically linked groups of items or high-level tasks. Sometimes they’re lists of “Books I want to read”. I organise the file as a single markdown file, where each project gets a H1 level heading and they’re sorted alphabetically by first character. Any actual todo items here aren’t conceived of as proper todos, but a direction to head when the project comes into my focus. In that event, any tasks to accomplish are transformed into actionable items and entered into my todo.txt file and prioritised properly. Any project notes are stored here as well. Here’s a snippet of the file:
Office / Cinema / Games room
============================
* PS2 games that would be good:
* Soul Blade original
* Tekken 1 - 5
* Soul reaver 1, 2, and defiance
* Battlefront 2
* Future Cop LAPD
* GTA III, Vice City, and San Andreas
* Get modern RaspPi with wifi and install a fileserver + media centre
Dad Death
=========
TODO:
* get old star wars comics valued
* Write recipes in old recipe book
It goes on. If I’ve got a project to send somebody something, I may store their address there. For my “reading” project; I write rough lists of books in various genres or languages that I want to look at. I often “think aloud” in the file, and write in a brain-dump tone.
If a project becomes big and starts requiring in-depth notes or thinking, it gets migrated into its own file under workbooks/. However, workbooks aren’t just larger projects. They’re also dedicated workspaces for particular concepts, areas of work, or longer notes. It’s easiest to explain with examples.
The way that I see every file under the workbooks/ folder is like a blank school book for a given topic. Your English workbook might be structured totally differently to your Chemistry or Maths workbook, the contents will be different and working in them looks different; but they’re all recognisably places where you write in them to do work. Hopefully that comes across!
One of my most frequently used workbooks is called open-contracting.md. That’s because one of my main areas of professional work (at the moment) is on the OCDS Helpdesk. The needs of that project are thus: I need to keep track of links to various documents and tools; I need to keep track of meeting notes; and I occasionally need to paste in some data to keep for longer than the scratchpad would be suited for storing. I’ll omit details, but that workbook is structured like the following:
---
title: Open Contracting
---
Links
============
* Links to various tools, wiki pages, guides, go here.
Drafts
============
* Longer term drafts go here, if necessary they're separated by H2 (##) titles.
* Drafts can be draft emails that are started one day, then get deprioritised and get picked up later
* or they're notes I leave myself for picking a task back up.
* or longer pieces of work that isn't suitable for writing in another repo
Meetings
==============
Meeting notes and minutes go here. Each meeting gets a H2 title with the ISO date and some details e.g.
## 2022-03-01 Initial Chat with Publisher XYZ
* Meeting notes here.
* Transcripts, bullets, key takeaways
* These all get captured.
* Actions get captured in the todo.txt file
That workbook structure allows me to manage that project nicely, with any actual todo items getting properly captured and prioritised in todo.txt. I have a similar setup for several of my other professional projects.
In contrast, the dreams.md workbook is mostly a chronological list of dreams that I remember. Whereas my esperanto.md workbook has sections for writing out messages to my penpal, for Esperanto links that I find interesting, for writing responses to practice exams, and for copying wholesale poems that I find beautiful. I keep a workbook for my home where I can collect information about fixing things, ideas for decorating, etc., and I keep a workbook for noting down things that my friends and family all like so that I can buy them thoughtful presents. I also keep a special deathbook.md file which contains instructions for if I die.
The structures within each workbook are therefore suited to the peculiarities of each ‘space’ or ‘project’, so it’s hard to give a way that each one is used. Some are used as giant long-term scratchpads. Workbooks occasionally get deleted, split, or merged. But generally, they are for long-term working and note-taking for different aspects of my life.
Managing my checklists
There is a small folder called checklists/ in the planner that I use to store my checklists for things. This has two files: monthly.md and weekly.md for monthly and weekly checklists respectively. It’s pretty straightforward.
These files just contain various checklists for my routine tasks like my backups or my laptop decluttering.
In future iterations of the planner it’s very likely that these will get condensed into a single file either under workbooks/ or by itself at the top level of the folder structure.
Todo.txt for managing my to do list
As noted earlier, I have long been a relatively devout user of todo.txt for managing my to do list. With todo.txt being a simple plain text oriented system, it felt like it had a natural home within my planner and so it was a simple matter to copy in my existing todo folder from my home directory into the planner repository, and begin managing it there.
There are four files in my planner’s todo/ folder. The most obvious ones are todo.txt, for storing active tasks structured using the todo.txt syntax, and done.txt which stores completed tasks with their completion dates. Entering tasks, completing tasks, and manipulating tasks between these two files is handled by a CLI python script, which I’ll discuss in a little bit. The main features I use in from todo.txt are prioritisation, contexts, and projects. This is a typical entry from my todo.txt file:
(A) @ocds +8039 ANAC revised data feedback
This is pretty standard todo.txt syntax but I’ll explain a little bit about how I’ve adapted it for use. For prioritisations I have the rule that no two things can be the same priority. Priority means the things that comes first, or precedes other things. It didn’t appear pluralised until the 1940s. This helps me focus on what needs doing first, which is ultimately where I flounder when I’m overloaded. I also try to keep my priorities pretty minimal. Todo.txt uses alphabetic priority so can go from A-Z, but I try to cap my prioritised tasks at a maximum of D or E. This means that I have to reprioritise relatively regularly, but since the shape of my work often changes and new things comes in to focus (and clients decide to reprioritise); this is sadly an effective way of managing this. The next thing on the line is the @context. In my professional life this is usually a domain of work, like a particular data standard or client project. The +project item generally represents a smaller piece of work within that scope. Numbered projects generally refer to a ticket in our ticketing system(s) for managing tasks so I can quickly find the ticket and do my work there. Otherwise it might be a chapter of a thesis, or something like +payroll or +chores. The rest of the line is the todo item itself. Sometimes these are super atomic and actionable like write skeleton of the findings section but if the process is pretty mechanical or understood they can also be relatively high level, as in the ANAC example above. GTG and todo.txt purists may be annoyed at how I’m using projects and contexts wrong, but I’ve adapted them for my brain and the realities of my working life. This is the joy of plain text; it’s totally flexible.
The backlog.txt file is my attempt at keeping my todo.txt file relatively clean and within the scope of “things that I need to be concerned about now”. My understanding is that this is a deviation from the traditional todo.txt methodology which relies heavily on prioritisation; however sometimes I need to capture something as a task and make it effectively invisible for a while. The reason for this is because my brain gets overwhelmed a little bit sometimes, and I struggle with prioritisation a lot. This is where backlog.txt helps me. It is structured in the exact same way as todo.txt except that the CLI script hasn’t got access to it (although I want to modify this) and therefore all edits are done manually and I can focus on my actual to do list. someday.txt is my manifestation of a GTG Someday Maybe list. This file is structured very differently to the others in that is mostly consists of high level notes items such as “look into motorcycle training”.
There is somewhat of a dialectic relationship between the todo/someday.txt file and the projects.md file. The former contains things that I will look into “when I’ve got the time”. If I’ve got a few hours spare of an afternoon or the willpower, I’ll crack the file open and choose something to look into. At this point it generally gets a heading in projects.md and the item is removed from someday.txt. If the activity sparks off any other ideas for things to do, these then get added back to someday.txt to start the cycle again.
Using a CLI script for the todo.txt file
Plain text pairs with the commandline pretty well, and I love hacking little scripts together that address very particular needs. Before putting together my planner, I had been using todo.txt for a while and made heavy use of the famous todo.sh commandline utility to ease my use of it. In fact, I then went on to write my own implementation which added features that I wanted for my own workflow; specifically automatic git committing whenever an item is added, removed, edited, or completed.
When thinking about the shape of my planner I wanted to have my cake and eat it. By this I mean, I wanted to migrate my todo.txt and related files into the planner but I also wanted to retain my commandline tooling. To do this, I adapted the tool so that my todo.py script took a configuration file, thus allowing me to point it at any file on my machine to use as the todo.txt file. I also added another parameter allowing the git repo to be in a separate, distinct, directory. This means that the script can have todo.txt etc all stored under the planner/todo folder; but also use the git repo stored under the base planner folder. Now whenever I use my CLI tool for my todo list, it automatically commits to the planner git repo ready for when I push at the end of the day.
Keeping logs
Some time during 2021, I decided to keep logs of a few things. These files are stored in the logs/ folder, and each take the form of a plain text .txt file, although could easily be parsed by any CSV parser.
Each log has the same format: an ISO 8601 date or full datetime (depending on the log’s scope) followed by a , and then by whatever the log entry is. You can see extracts from some of my logs on my 2021 solstice review posts (Summer, Winter).
The logs are used pretty frequently, although some don’t get touched for a while. My most frequently used logs are:
- books.txt
- movies.txt
- albums.txt
And I have others for things such as logging symptoms of illness in case they become important, or tracking income from my father’s estate so that I understand how much of it has come through vs my own savings (which helps me figure out that I haven’t wasted any of it…).
Inspired by my todo.txt CLI utility, I took a similar approach when I began designing a small logging utility to help me create logs quickly. This utility is much less complete, and I do want to finish it someday, but has made it very quick and easy to rapidly log albums, music, etc as I listen to them without needing to manually type a datetime. This said, I often write out logs by hand. If I’ve a few entries to log from my phone, or if they’re in the past, I’ll need to log them by hand. This hasn’t got irritating enough yet for me to want to write the feature into the CLI tool; but one day I might.
Keeping in sync with my phone
In short, I don’t.
My philosophy behind this is that I really don’t need to have access to my planner on my phone at all. I don’t want to be adding todo items or checking off tasks on the move. It’s conceivable that I might want to look at something from my planner on my phone, but generally speaking my life doesn’t work like that right now. I’m not travelling constantly (thank the gods), and I work from home between two laptops (if one breaks). While I do use my planner for “Life” stuff; it’s dominated by my professional work and there is rarely something in my non-professional life that fits the category of urgent enough to be written down but not urgent enough to do right now. My planner enhances my personal life, but it doesn’t address problems really. Even my todo.txt file mostly contains professional tasks, and the personal tasks it does contain can simply be checked in the morning as I turn on my laptop.
Up until very recently I used Markor on my phone to jot down notes and keep small logs to be transferred into the planner manually. The Quicknote feature functions remarkably similar to the scratchpad file in my planner in that it is a single text file that is designed to be constantly edited. So it was a good place to jot things on the move. It effectively acted like a OBTF on my phone, but one that got emptied or edited quite regularly. If my partner and I were watching a movie, it would get logged in the Quicknote on the phone and then manually typed up in the planner later and removed from the file on the phone. Other than logs, it’s rare something needs to get migrated across from my phone to my planner.
I still take notes on my phone, and they function in the same way. However, I’ve stopped using Markor in favour of Nextcloud Notes. This decision was tough as I thoroughly love Markor; but it was going in the direction of more complexity and feature-richness when actually what I need is just a plain text-with-markdown notepad on my phone. Nextcloud notes has a lovely, simple, interface and has the bonus of already being in sync with my Nextcloud instance. I don’t really make use of this at the moment but it’s nice to know that if I needed quick access to some notes from my phone, via my laptop, then I could do this quickly and easily.
What doesn’t go in the planner
The planner is also defined by what sits out of its scope. For me, this mostly consists of the actual work or output from projects. The planner allows me an overview of everything that happens, but it’s not an OBTF or where I want to do my creative or productive work outside of the ideas or draft emails I write in the scratchpad.
I write a lot, relatively. Blogs, papers, fiction, and the odd bit of poetry. These all have their own separate projects folders on my machine despite the fact that they are, for the most part, mostly just plain text. The planner is for helping me organise thoughts and manage my life. It’s not my typewriter as well.
I also find it difficult to manage appointments and keep dates in my head using the planner. Emulating Dan, I tried out a calendar.txt file. I wrote key dates in at the top and tried to keep a log of all upcoming events. I never wrote in it or looked at it, even with reminders on my phone. I bought a cheap analogue week-to-view pocket diary which I’ve been trialling as my memory-enhancement for dates and events. I’ve had mixed successes, but more than the plain text version. And this is fine. I’m using the affordances of each medium to suit my particular needs; and that doesn’t lesson the importance of my plain text planner in my life.
Finally, I don’t keep a diary in the planner. Some day this might change, and it was so tempting to try and strongarm jrnl.sh into the system. I do keep a physical journal, which means that I don’t need a digital one for now.
An average day in the planner
Like one would keep a physical planner open on their desk, I tend to keep the planner open all the time on my laptop.
The fist thing I do when I log into my machine is open a terminal which occupies half of a screen (vertically). I’m a heavy user of virtual workspaces, so I ensure this terminal sits across these by telling X-window to make it visible across all workspaces. I then use the terminal to navigate to my planner/ folder and open the entire folder in my text editor. This means that I get access to the entire planner through the tree menu at the left hand side of the editor. The scratchpad is always open, and I open workbooks as and when I need them. If I’m at my desk, with two monitors, the planner gets full-screened and occupies my entire laptop screen and also is persistent across workspaces. This means I can use the external screen for calls, shared documents etc while taking notes in the scratchpad or a workbook pretty easily. If I’m just on my laptop, the text editor will remain on a single workspace where I can quickly navigate to it to enter or retrieve information.
Throughout the day I’m mostly working inside a workbook or the scratchpad. If I’m listening to music, I use a commandline utility to log the albums. At the same time, I use the todo.txt CLI utility to manipulate items in my todo files.
At the end of the day, I’ve generally accumulated anywhere between 5 to 40 commits (depending on the complexity of the workday and how good I am at committing), wherein I’ll give everything a quick glance over to make sure I capture any final notes before pushing the repo.
Summary
In this post I highlighted my use of a single plain text-oriented git repo for managing my professional and personal life, which I adapted from Dan Lucraft’s “Plain text personal organizer” and I call my “Plain text Planner”. I outlined how I use a plain text scratchpad, and have a series of “workbooks” that I use to manage larger projects or scopes within my life, and how my low-level tasks are captured by integrating the todo.txt methodology within the context of the planner (aided by some CLI tools). I also use the planner to store logs and checklists, keeping them close to hand.
If you’re into plain text and are sick of productivity porn, and want to build your own system that works for you: I heartily encourage you to think about designing your own version of this. Whether you conceptualise it as a personal organiser or a planner, or a diary; that’s your call. There’s so much you can do with a little understanding of your own needs, and a lot of plain text.