[TxMt] GTD Upgraded

Daniel Käsmayr daniel at kaesmayr.net
Fri Jun 9 18:32:48 UTC 2006


Mike,

> First, on contexts, I thought that "TODO", "CALL", etc. were  
> contexts (in my mind, I use TODO for a physical action or something  
> that doesn't fall into another context).  Maybe I'm missing  
> something here.  And maybe I need to explain how I use the GTD  
> bundle betetr.  I created a GTD project in TextMate where I add a  
> *.gtd file for each project, e.g. "stuff to do around the house,"  
> "paint the living room," etc.  Then I add tasks, using the TODO,  
> CALL, etc. contexts.  Finally, to use what I've done in context, I  
> do a "view GTD tasks" (control-shift-T) to group my tasks  by context.

Well, it always depends. For me contexts are such things like "@lab",  
"@home", "@online" - where I can have TODOs, EMAILs or phone calls,  
as I don't really like to mix my private life and my work(s), it does  
make much more sense to actually split by location based contexts. I  
am not sure if it would be necessary to have these contexts be  
changeable as easily as FMP does (which creates new txt files for new  
contexts, beware spelling errors).
I do like your approach to projects, this is somewhat similar to what  
I am doing, but I haven't really found a way I am really happy with  
(yet). What I have in my project.txt files is much more than just a  
list of nextactions, but also my motivation, the expected outcomes,  
brainstomring and notes as well as those nextactions and dones  
(a.k.a. as "Log"). And in this sense the FMP does not work as I would  
need it to scan all my project files and then compile the context  
based nextaction files. However your approach to list everything is  
also too much for me. I would need something in between, such as some  
way to actually create .txt files that are context sensitive, but do  
collect all my project's stuff. And I would love to have "done"  
states transferred back to the project.txt files as well, just to the  
corresponding logfile section. And I also don't want to have all  
future nextactions there, just some form of subset for the "really"  
next actions… (together with some form of metadata from its project,  
maybe also with some form of time stamp when it was created or when  
it is due…).
In some way this may be too complex to be done, but maybe not. I will  
take a look ;)


> I wrote to Nick Fagerlund (FMP creator) and he has given me  
> permission to include FMP in the GTD bundle.  I think that FMP is a  
> great tool, but it works the opposite of how I think.  I like to  
> "think in projects, execute in context" where FMP is designed to  
> take a text file with more-or-less random categories and split it  
> out into separate lists.

Yeah, FMP tends to enforce context over anything else. When you  
integrate it into the bundle, are you going to make it "versatile"  
via TM Environment variables? I have it running here now, but with  
hard coded paths as this was the easiest at the moment and I had no  
clue yet if I actually could use FMP. (which I know now does not  
nearly help as I thought it would.) FMP, I believe, almost requires  
you to use Quicksilver for task creation (…it was created for this  
purpose, i think?).

Let's see where additions to the bundle will take us and keep the  
discussion alive. At least I will probably learn enough about  
programming as well as gtd by just reflecting more and writing about  
it ;) And, as we all know, things will get done in the meantime… ahh,  
the gtd geekness has this affinity for the meta-level, where not  
"getting things done" but "getting getting things done" becomes the  
issue… lol.

Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3996 bytes
Desc: not available
URL: <http://lists.macromates.com/textmate/attachments/20060609/9c8d8c4d/attachment-0001.p7s>


More information about the textmate mailing list