I still have three different ways to store a running list: * big ass text file * wiki page * cheap pocket notebook

All are useful. The text file was fine when I carried my Zaurus or Palm around, but data-entry was slow & I switched to the notebook. I use it when I need to add something & am not at a computer.

I normally run SSH & can therefore often access the text file remotely. I don’t like the idea of keeping it on a USB keydrive, but some people do.

The wiki is there for things I might need some accountability for & commitments I make for others.

Now, more on the big text file…

I still sometimes use a pseudo-wiki markup, which gives it some kind of structure (with headings and such). I have a large space after the bottom organized line so I can easily drop unsorted stuff. Sometimes I just “echo ‘thing to remember’ >> big.txt. I also have a bash alias so I only have to type “b thing to remember’. This means I don’t have to open up vim. vim’s ‘dd’ makes it easy to cut a line & insert it elsewhere to cleanup the file a little bit.

Another handy organization technique in vim is to use code-folding on your sections/subsections.

If I need to find something, I will normally just use grep on the textfile. But vim’s search capabilities are also nice.

I don’t keep multiple revisions of this running textfile. Other things which need multiple revisions are in their own text files & this is why I use grep: I search through all text files in a directory & can use it recursively if I need to. subversion or other real version control software is really ideal for versioning the text.

I would think that maybe an HTML’d file with references at the beginning would be easy to navigate. like a link to #shoplist for you latest shopping list, and when you edit the file just ‘tag’ the place with #whatever.

I have been experimenting with Giles’s method recently — the tagging allows for some complex filtering and manipulation on the CLI that you just don’t get otherwise. However, one of the key points of this plaintext idea is that you can use whatever text tool you want, i.e. vim, TextWrangler, TextEdit, whatever.

This has fit in quite well with my effort lately to do what I’m calling Reducing Friction — smoothing the process of getting items into the todo queue, worked on, and into the done list as much as possible. This includes reducing distractions in the working environment, visual and otherwise.

I’ve written up an article here about it, expanding the thought. Thanks to Giles for the inspiration.

Funny that this should come up. Being an old Unix grouch, I started a prototype GTD system where I just have all of my next actions in a single file — one task per line with “[Context]” thrown on the end. I was pulling the relevant context using grep at the command line. Frex, if I wanted to look at my “Out of House]” context I typed:

grep -i “out of house” nextactions.txt

This looked promising as Hell, but in the end I decided to stick with OmniOutliner for the time being because I decided that I was shaving the proverbial yak. The urge to tinker with the system was overtaking me, and I made myself stop.

I’m just wondering if you can work with other people that way…I could imagine keeping all my information and work in one place, organized by time—after all, you can do only one thing at a time—but once you have to share anything with other people you’re burdening them with your entire system.

I’m having enough trouble keeping just one folder for each project (rather than a deeper hierarchy), and people I work with often have trouble finding what I’m working on (all our work is online).

Slightly off-topic, but: this reminds me of how MPW (the “Macintosh Programmers’ Workbench”) programmers would program much of the time, on Mac OS 9 and earlier versions, before the NeXT merger and Mac OS X. MPW kept a scrolling history that was a bit more “active” than normal terminal windows are. Instead of having shell script commands in a ~/bin directory, you’d have a part of your transcript that you could easily find, select and then hit Enter to execute it.

MPW was like a bizarro-world version of Unix. It worked in its own world, but everything seemed somehow inside-out to me.

I just started doing what Nikhil Mulani said, and writing up a big ole HTML file, complete with reference links at the top.

The plus side is that the document structure is farily simple (headers for headers, lists for lists). Unfortunately, the markup can add a lot to the file-size of the, essentially, plaintext file, plus, for any real meaning, you need a browser to view it. Not really a minus, but an extra requirement for viewing them.

I’ve been doing this for a while, using a single TODO.txt file. I personally find it very hard to use anything that requires more effort that opening a text file (tried InstiWiki and Notepads, doesn’t work for me), so I’ve made it work.

The top of the file is the TODO list, in descending order. After that is a calendar, which is a descending order list of dates/thing to do on it entries. After that is a log, where I jot daily (or fairly regular) notes about what I’m doing.

Currently at 100kb and climbing. Works well for me. I think it encourages judiciousness about what goes in to prevent excessive bloat, meaning what goes in is more likely to get done, and trivialities or distractions get pruned early.

Bigger ideas and things that require more detail get broken into their own files though.

On the computer, I use planner-mode (EmacsWiki) in emacs. Made up of flat text files that all live in one directory, searches are easy using grep. Cross-referencing and meta-information is all hyperlinked, so you can move around really easily.

I don’t use it for a todo-list anymore (3x5s are my favorite for that right now) but it does those very well.

There are actually people who have switched to emacs just to use this bit of software!

I have to second Bob’s comments. As I read Giles’ piece, I kept thinking “that reminds me of MPW”. I used to love MPW, and had highly organized, but very long, worksheets. Is there something like that around that combines: efficient handling of big-ass text, command-line execution anywhere, and scripting? And it has to run fast, fast, fast.