Joseph Hallenbeck

May 2, 2016

Goodbye Trello, Hello Todo.txt

Filed under: Software Development — Tags: , — Joseph @ 9:00 am

Flattr this!

In 2013, I was fresh on my switch from Windows to Linux as my full-time OS. I was reading books like David Allen’s Getting Things Done and looking for a good digital planning system. Enter Gina Trapani’s Todotxt script.

Todo.txt allowed for command line todo lists. Every was stored in a plaintext file, easily editable with any text editor or automated via the command line. I used it for roughly a year. At the time I both loved and hated using Todo.txt.

On the one hand, it was easily automated. I could set up daily and weekly tasks to be automatically populated to my list in the morning. I could easily bulk edit things in VIM.

But there was still some big pain points. My lists tended to get way too long — scrolled right off the top of my screen. There was no easy way for managing multiple todo files. There also wasn’t much for sorting. The result was that managing my lists and getting an overview of everything became increasingly difficult.

When my employer started using Trello for product management, I saw my solution. Trello does a great job of visualizing where all my tasks belong. Following GTD, I had a backlog column, next actions column, today column, in progress, and done. Moving cards between columns let me visually see the flow of work through the day. A big tickler board kept all my long-term ideas.

Now in 2016, I find myself re-installing Todo.txt and giving Trello the boot. Why if it was such an excellent system?

Goodbye Trello

There are a number of pain points that Trello simply cannot get over that Todo.txt solves easily:

Vendor Lock-in

A theme for a lot of my projects this first quarter of 2016 has been a move away from Vendor lock in. I got rid of my IDE and switched back to developing using VIM. This got me to thinking about how many other products I use that have vendor-lock-in. Evernote instead of just keeping plaintext files. Dropbox instead of using rsync. And Trello instead of Todo.txt.

With Trello, my done lists, my massive tickler list of project ideas, and my entire workflow is dependent upon the continued existence of Trello the company and it’s good graces to continue hosting all of this content for free.

Now Trello does have an export feature, but the result is a massive json blob. It might as well be binary for as much use as I will get out of it. I most certainly will be backing up all my trello boards. Yet, if I ever wanted to make use of this data, I will first need to write some kind of interpretor for it.

Todo.txt, as a plaintext file manager is to todo lists what Markdown is to Word Documents. It’s open, interchangeable, can be opened nearly any file system. It will follow me for year’s to come.

Difficult Automation

Switching back to VIM and working on the terminal all the time made me realize just how many computing tasks I have left un-automated.

In planning my daily todo tasks there are a number of recurring todos. A daily stand up starts my work day. A sprint planning meeting occurs every other week. Duolingo calls my daily French learning session. Monthly bills need to be paid.

On Trello entering these items into my board is a manual exercise. I keep a second board of “reoccurring” tasks that I copy over at the start of each sprint. It takes me thirty some minutes just to do this.

Now Trello does have an API, but I would need to learn it, probably create some kind of developer account, get API keys, compose some sizable application to interface with that API, make REST calls. It would take me probably a week’s worth of work to automate that entire process.

With Todo.txt, and a little BASH-fu and a cronjob, this all gets automated away. Every night my daily tasks get added to my todo, every sprint my per-sprint tasks get added to my todo. At the end of the month a note to pay my bills shows up on my todo. This gets offloaded so I no longer need to think about it.

Task Creation Friction

GUI’s add friction to any task.

Trello is no different in that regard. If I want to add a new task, I need to fire up a browser, navigate to Trello (assuming I even have an internet connection), create the card, name it, click a bunch of buttons to add a label. Sometimes, I just don’t want to do all of this, often times I find that I don’t sufficiently break a task down into small enough tasks purely out of a resistance to creating more cards., being on the command line means I need no internet connection, I can simply start typing to add my task, and there is little overhead in truly breaking any project down into atomic tasks that can be accomplished in a single Pomodoro.


After considering these options, I decided to revert to using After a week of being back, I find that I love it. I am still working out my system for using It truly is powerful. I’ve already discovered quite a few commands and options that I had no idea even existed before (I never realized there is a means of doing a logical or for terms or excluding terms via -TERM).

I could easily write up an entire second post about how to manage todos, how to install the script, get yourself running, useful aliases and methods for creating new add ons and automating things. Once I really get my daily system going, I could probably write a whole post on that as well.

Plaintext Planning

I would highly recommend a read through Michael Descy’s Plainttext Productivity website as the tips are quite above board. The biggest take away is priority management. Only use three or four priorities and use them to management where an task exists in the GTD workflow:

  • (A): Tasks that are in progress. Keep this down to three or four tasks at a time.
  • (B): Tasks that I will get to today
  • (C): Next actions that can be started now. (Descy uses this for “Next Actions this week”)
  • (D): On hold (Descy uses this for “Next Actions next week”)

Everything else is in the backlog which for me is items to be done this quarter. Anything further back goes on the tickler to be evaluated some day and added at my leisure.

Add-Ons & Set Up

A very brief overview of my current set up.

First, I have the todo.txt-cli script installed in my dotfiles repository which has it’s own script for installing all of my related configuration files on any system I touch. The todo lists themselves are in their own separate repository since I don’t manage todos on every system that I touch.

I follow the instructions for setting up auto completion. I also set up a number of aliases for different todo lists:

  • todo: for my daily, sprint, and quarterly task list
  • todot: for managing my tickler list
  • todos: for managing my shopping list

The aliases use the -a flag since I prefer to not auto archive by default.
Each alias has it’s own todo.cfg file which each sources a base.cfg file and only exports configurations that are unique to that command. As a base, I changed my priority colors to Blue, Green, Brown, and Red solarized values for the A-D priorities. Changed the project color to red and left the context a nice light gray.

As for the add ons, I added:

  • archive for archiving only selected items
  • edit for quickly opening the todo in VIM
  • sync and it’s requirements commit, pull and push for quick version control my todo lists.
  • projectview has some pretty formatting for project lists
  • recur for automating recuring tasks. I tried the ice_recur module but simply could not get it to work on my system.
  • xp another task visulation. This time for done tasks.
  • pri and rm (with a soft link for pri to p as a shortcut) for bulk editing priorities and deletions
  • lsgp/lsgc another project and context visualization.

Still Some Rough Spots

There are still some rough spots in land. First, sorting is still not quite perfect. Ideally, if I type todo lsp, I would like to have all my tasks listed by priority, then line number grouped by project. The best that I can do right now is by priority and then line number. Project grouping only occurs if I group the project lines together in VIM.

Secondly, the one big item that Trello had going for it was it’s phone app. This made adding tasks on the go quite easy and made looking things up easy as well.
Perhaps some of the various todo apps will have the functionality that I need, or perhaps I will need to compose my own app to meet my needs. The joy of the matter is though, I’m not locked in. I can easily develop that app if I so choose.

May 5, 2014

The Glories of Text Files: On Using Vim for Code and Prose

Filed under: Software Development — Tags: — Joseph @ 9:01 pm

Flattr this!

Were to begin? This post is a kind of smörgåsbord of random thoughts and musing regarding editing and creating documents. It all really began when I started contemplating learning LaTeX, which lead to a good deal of time spent thinking about what is a document and from there to extrapolating much of the best-practices for web development into a wider sense. Namely, that a web page is merely a marked-up document and that the principles of separating style from content ought be considered in our document processing.

I think that Allin Cottrell says it best: Word Processors are Stupid and Inefficient. This is something, that I think anyone who spends a good deal of time editing text begins to realize. I recall long hours in college editing work cited lists to carefully format them into their specified manners. Even more, I recall hours writing long form Dungeons and Dragons Adventures to submit to Dungeon Magazine and all the pedantic formatting that it required.

XKCD 1360

Not surprisingly, early on in my computing, I had turned to various forms of mark up for my writing — HTML, simple text files, anything at all to just get away from the mess that was the Word Processor. It seems that I was on to something, even though I was unaware that the problem of separating content from the issues of styling (or more properly: typesetting) had long been a solved problem.

If I were to paraphrase Cottrell’s points about the disadvantages of Word Processors and advantages of typesetting it would be:

  • Text editing allows us to focus on the content and leave stying for latter (Which is often a solved problem if your content is going on a website or submitting to a publication)
  • With separate concerns we can use software like Pandoc to export our text file into LaTeX, PDF, Doc files, HTML, whatever use we want in whatever style that pleases us without needing to go back and edit the content itself.
  • Text is pretty much ubiquitous, it works on nearly every computer and is resilient against file corruption.

Since Cottrell wrote his document we’ve also got an upsurge in easy-to-use and reader-friendly mark up languages like MarkDown and reStructured text which allows us to create text files that are readable as both a text file and exportable into a format that can be compiled into a beautiful print document via LaTex. In fact, this entire blog is done in MarkDown and as of late, I’ve turned to writing my articles as separate text files in VIM and just uploading them to WordPress after the fact.


Enter VIM, my text editor of choice. Sublime seems to be getting a lot of traction amongst my fellow developers, but as far as I know Sublime still lacks terminal support — so I stick it out with VIM. That said, I really only started to master VIM about a year ago. Before then, my interaction with VIM was limited to random encounters changing configuration files on production servers. At the time, I only really learned the bare minimum to get by — how to open a file, get into insert mode, and save.

A year ago, I decided I really needed to try to master VIM. So I sat down and did the various tutorials. Made cheat sheets. I got decent at it, but not perfect. Right now, I’m refreshing myself and I’m setting a goal of setting aside NetBeans for my next project to do it all in VIM as well as officially tossing the Word Processor for writing my prose in VIM as well.

For those who want to follow along, I’ve created a public git repository with my VIM configuration.

VIM for Code

enter image description here

If I plan on developing an entire website with just VIM, then I really need to get VIM tweaked out to do exactly what I want for development. Now, I read a lot of tutorials, but I found Mir Nazim’s “List of VIM Plugins I Use with Mini Tutorials” to be a very good start.

I think the take aways from Nazim’s article are:

  • Install Pathogen. This is pretty much the go-to package manager for VIM plugins.
  • Put your ~/.vim directory into a git repository. Move your ~/.vimrc into your ~/.vim directory and then create a link to it. Get this set up on all the machines you work on and then you can easily sync any change to your configuration across all of your platforms.
  • Use git submodules to manage all of your VIM plugins.

The Plugins

For myself, I use the following plugins in my VIM install currently:

  • closetag Automatically closed open HTML tags
  • delimitmate Automatically closes quotes, parentheses, brackets
  • fugitive For GIT inside VIM (haven’t made much use of this one so far)
  • nerdtree The go-to for in VIM directory navigation and opening files.
  • pyflakes For Python Syntax checking
  • supertab For word completion
  • syntastic For advanced syntax highlighting and error checking code

I’ll leave you in Nazim’s exellent hands for how to install and configure these.

The .vimrc File

A few notes on my choices of settings in the .vimrc file:

set encoding=utf-8
set number
set ruler
set autoindent

This set sets our internal character encoding to utf-8, turns on line numbers and the rule by default. Also, autoindent, because it’s cool.

set tabstop=4
set shiftwidth=4
set expandtab

These three defines our tabs as being four spaces and sets VIM to automatically expand any tab characters into being four spaces.

nnoremap <C-t> :tabnew<CR>
map <C-n> :NERDTree<cr>

This combination creates two new key bindings. First, we can now hit Ctrl+t to open a new tab in VIM. The second allows us to hit Ctrl+n to pop open NERDTree so we can navigate around the file system and select files to open. A quick note: in NERDTree pressing Shift+t opens a file in a new tab. An extremely useful shortcut to know.

syntax on
filetype on
filetype plugin indent on
let g:syntastic_check_on_open=1
let g:syntastic_enable_signs=1
let g:syntastic_mod_map = { 'mode': 'active '
  \ 'activeIfiletypes': ['python', 'php'],
  \ 'passive_filetypes': ['html'] }
let g:syntastic_python_checkers = ['pyflakes']
let g:syntastic_python_flake8_args = '--ignore="E501,E302,E261,E701,E241, 
let g:syntastic_php_checkers=['php','phpcs','phpmd']

Supposedly all of this should enable syntax checking and highlighting for Python and PHP. Python seems to work quite well. PHP, unfoortunately, requires you to write out the file to see the errors.

Lastly, we want to make word-search a little looser so by default we adjust some of the search parameters:

set ignorecase
set smartcase
set gdefault
set incsearch
set hlsearch

I will skip the WordProcessorMode and CodeMode commands for latter, for now let’s skip to the last three lines:

if filereadable(".vim.custom")
  so .vim.custom

These three lines sets up VIM to look for a .vim.custom file in the directory that it is running from and then essentially append it to the end of our .vimrc. This allows us to create custom configurations for VIM on a project-by-project basis.

VIM for Prose

Vim in Prose Mode

I began this talk with a discussion on why we should use a text editor for editing our prose. VIM works extremely well for writing code. I am not yet entirely sold on it being the editor for prose, although I do think that any prose-text editor had better come with VIM bindings to be worth its salt.

Right now, I am using VIM to write this and will probably be using VIM to work on a lot of long-length prose. This gives us a number of great advantages:

  • Files are small
  • Files avoid corruption. Imagine this, if one byte of this file gets corrupted what happens? I have a misspelled word. If this happened in a binary file who knows if it could be recovered.
  • I can use my programming skills to do such things as incorporate tables via comma-separated-files, images, or break this out into separate files and compile them into a larger document.
  • I can write it using whatever mark up language I want (in this case MarkDown) and then use a converter like Pandoc to export into nearly any mark up language or file format.
  • I can take advantage of all of VIM’s keyboard functions to keep my hands on the keyboard and my mind in the flow of putting words on paper.

So what have I done to get VIM working for prose? I dug through a lot of tutorials and even used Vimroom for a while. At first, I loved Vimroom, but over the course of a week the bugs and poor user interface and the abandon-ware feel of Vimroom lead me to abandoning it.

There’s a number of bugs that simply annoyed me. For example, the some color scheme throws all kinds of errors when toggling Vimroom, and quiting out of Vimroom without toggling it off first requires repeated closing empty buffers to get back to the terminal. There also appears to break the drop-downs in SuperTab causing them to appear but only to allow you to select the first item in the drop down.

So after a week of Vimroom, I set out to roll my own solution. The solution was to add two commands to Vim — :Code and :Prose. These toggle between the settings I want when writing code and the settings I want for prose.

func! WordProcessorMode()
  set formatoptions=aw2tq
  set laststus=0
  set foldcolumn=12
  set nonumber
  higlight! link FoldColumn Normal
  setlocal spell spelllang=en_us
  nnoremap \s eas<C-X><C-S>
com! Prose call WordProcessorMode()

This snippet creates a WordProcessorMode function and then on the last line, attaches to a command :Prose. Let’s take a look at each line in part.

set formatoptions turns on an umber of important features. With a we set our text to automatically wrap when it reaches our textwidth values. In this case, it is 80 characters. Next, w defines our paragraphs as being separated by a blank line. t sets our text to be automatically formatted to text width and q allows us to use the gq command to automatically reformat selected text.
Note: you can can use gGgq to select the entirety of a document and reformat it.

The foldcolumn and highlight lines sets a 12 column margin on the left side of our text and sets the color of that column to the same as our background.

With spell on misspelled words will appear highlighted, we can tab through the misspelling via [s and ]s to jump to the previous and next misspelling respectively. Once our cursor is on a misspelled word hitting z= brings up our corrections options and zg adds it to our personal dictionary. One addition makes correcting words so much easier:

nnoremap \s eas<C-X><C-S>

This displayed the spelling correction options in an in place drop-down!

Before we forget. We need a function to turn all this back off again if we wanted to jump back into code mode:

func! CodeMode()
  set formatoptions=cql
  set number
  set ruler
  set laststatus=1
  set foldcolumn-0
  setlocal nospell
com! code call CodeMode()
call CodeMode()

This function resets our environment back into code mode, and of course we call the function on start up as well so we always begin VIM in code mode.

Last: If you, like me, plan on using MarkDown as your prose mark up language of choice, grab the vim-markdown plugin which gives me excellent highlighting of the MarkDown syntax.

Vim Color Scheme: Solarize

There is a bunch of color schemes available in VIM via the colorscheme command, but honestly nothing really beats out the simple, thought out beauty of the Solarize color scheme.

The problem is getting it to work in the console. You might notice that my repository does not include the popular vim-solarize plugin. The reason? In terminal mode the Solarize color scheme breaks horribly.

It took a while for me to discover the solution to this problem: change the terminal. Granted, this solution requires you to have a desire to have the Solarize color scheme throughout your terminal experience.

Sigurd Gartmann has a nice repository on git hub that, once installed allows for toggling the terminal into dark or light mode of the Solarized color scheme.

So there you go, a complete walk through for using VIM for both development (in this case web development) and prose writing. Enjoy.

Copyright 2011 - 2017 Joseph Hallenbeck Powered by WordPress