[TxMt] GTD Upgraded

[Ron Rosson]

This just came to me.. An idea for a tickler file where we could put  
either a date or time or both in the beginning of the line along with  
the context and have a script with growl support run through this  
file or files and if it has the dat/time either/or and it is at that  
time (or a predefined interval in the script) to alert you via growl  
that this item needs some attention.

Hopefully I completed that thought.

-Ron


On Jun 15, 2006, at 2:25 PM, Ron Rosson wrote:

> Jonathan,
>   You just thru my thought process in to overdrive. Since this  
> thread has started I have made little notes of how I am doing  
> things with the Bundle and the little caveats I come across that at  
> the moment are not working with my thought process. With what you  
> have added to the discussion below I would just like to thank you.  
> You got me thinking about my process and to see if what I have  
> going is efficient or making a mountain out of a mole hill.
>
> I too wait to see what Mike does with the bundle.
>
> -Ron
>
> On Jun 15, 2006, at 2:04 PM, Jonathan Ragan-Kelley wrote:
>
>> As a very long-time Outliner GTDer (I was actually using my own very
>> similar system for well over a year before Ethan launched kGTD, and
>> tried Life Balance for 6 months before that, and so on), I like the
>> direction this bundle could go, so I'm excited to see so much early
>> activity.
>>
>> One thing this latest conversation brings up:
>>
>> Why should the user have to explicitly specify a list of contexts  
>> in a
>> separate file -- why couldn't contexts just be inferred from those  
>> the
>> user is already using, like in FMP?  They could of course be  
>> cached in
>> a .context_cache file for faster access, but it seems to me that
>> having an explicit, separate configuration file is entirely
>> unnecessary.
>>
>> (As an aside, I really like the @.* tab trigger idea for user-defined
>> contexts, btw -- and that's where I see the cache file helping, vs.
>> having to parse contexts out of each and every project file every
>> time.)
>>
>>
>> The other complexity I don't yet fully grok is why there is this
>> notion of task-type that's orthogonal to both context and project.
>>> From my own experience, at least, this sort of added layer of
>> complexity over and above basic GTD (traditionally you just have
>> @email, @work and @home, not tasks vs. email vs. ? | @home vs. @work
>> leading to email at home vs. task at work) always winds up getting trimmed
>> away in the end, and, where the distinction is genuinely useful, it's
>> usually because you actually have a new context distinction
>> (@work-email and @home-email), not because these sorts of things need
>> to be fundamentally orthogonal throughout, complexifying the system
>> even in cases where the location is irrelevant.
>>
>> In short, I think using the traditional GTD sense of a single, flat
>> notion of context (rather than both location and task-type) is  
>> just as
>> powerful for those users who want to have location-specific bins, but
>> it's no more complex for those who don't, or, more generally, most of
>> us who don't *for most contexts*.
>>
>>
>> Anyway, just my 2c after watching from a distance for a while.  I'm
>> quite interested to see where this goes.
>> -jrk
>>
>>
>> On 6/14/06, Ron Rosson <oneinsanedotnet at gmail.com> wrote:
>>> >
>>> > On Jun 14, 2006, at 7:18 PM, Ron Rosson wrote:
>>> >
>>> >>
>>> >> On Jun 14, 2006, at 6:10 PM, Richard Sandilands wrote:
>>> >>
>>> >>> Having a text file of customisable contexts that was then  
>>> scanned
>>> >>> by your bundle woudl be the ultimate for me - watch out Kinkless
>>> >>> GTD!
>>> >>>
>>> >>> I suppose the user would then have to set up their own tab-
>>> >>> activated snippets for each context if they wanted them but that
>>> >>> is a small price to pay.
>>> >>
>>> >>
>>> >> Now you got me drooling.   ;-). What if it took the first
>>> >> character of the context and combined it with the action required
>>> >> for that item. ie....
>>> >>
>>> >> tw == work task
>>> >> tm == mac task
>>> >> th == home task
>>> >> etc etc.
>>> >>
>>> >> Just throwing out ideas
>>> >>
>>> >> -Ron
>>> >
>>> > Great start!  Here's kind of the format I envision:
>>> >
>>> > #Base Contexts, with built in tab commands
>>> > TASK | t | 00ff00 # context | tab key | color for list view
>>> > HOME_TASK | th | 000f00
>>> > ...
>>> > #User Defined Contexts that use a generic tab command (say, "@") +
>>> > a key combination
>>> > SCHOOL | s | ff0000 #The user would type "@ s" and then tab to  
>>> make
>>> > this work
>>> > ...
>>> >
>>> > How does that sound?
>>>
>>> Like what the doctor ordered.  ;-) to me. Since right now I am
>>> working full time, going to school four nights a week and still
>>> maintaining normal household maintenance and then throw in calls I
>>> need to make errands I need to run etc. This is is going to give
>>> kinkless a run for its money. While you are refining would it be
>>> possible to drop the extension of the filenames when displaying the
>>> list and active list. (Kinda beautify it a bit).
>>>
>>> - -Ron
>>>
>>> P.S. Would it be possible to have a task like "go Shopping" and then
>>> link another list to the go shopping list with the list of things  
>>> you
>>> needed to buy.
>>>
>>> Just came to me.. Thought I would bring it up.
>>>
>
> ______________________________________________________________________
> For new threads USE THIS: textmate at lists.macromates.com
> (threading gets destroyed and the universe will collapse if you don't)
> http://lists.macromates.com/mailman/listinfo/textmate