[emacs-wiki-discuss] Re: More flexibly named "Time" pages

[Greg Novak]

* Sacha Chua wrote:
> > Specifically, I'd like pages like 2005.August, 2005.September.Week1,
> > 2005.Year, etc, to be treated just like day pages are treated now.
> > I'd like to be able to use planner-copy-or-move-task to reschedule a
>
> Hmm. Can you help think of a nice way to mix year, week, and day views
> so that you don't have to check three places for tasks? It would be
> great if we could get this to work.

Hmm... well, this is substantially more complicated than what I want.  In 
fact, for this particular application I'd consider it an _advantage_ to 
have to check multiple pages for tasks.  The reason is this: at the 
moment, I have _way_ _too_ _many_ bite-sized tasks--I'm working on a PhD, 
and it's easy to think of a million future research directions that might 
be interesting.  Then people ask me to do things, draw plots, etc.  The 
result is that I'm completely swimming in details and unable to keep track 
of the big picture.

What I'm finding works better for me is to plan from the top down, rather 
than the bottom up.  That is, each month I choose the two or three things 
that are my _highest_ large scale priorities for that month.  Those go on 
the "month" page, and _no_ other tasks, so that it's not cluttered with 
details.  At the beginning of each week, I look at the month page and 
think about how those tasks break down into smaller tasks.  Then I 
choose my _highest_ two or three week-scale priorities for the week. 
Finally, at the beginning of each day I check the week page and plan my 
day, with my primary goals for the week in mind.

The way this works in practice is that in my plan pages, I have "normal" 
tasks that can be completed in a day, then week-scale tasks with "W: " at 
the beginning, month-scale tasks with "M:" at the beginning, etc.  Month 
pages contain only month tasks, etc.

What I see as the virtue of this is that you can think about large-scale 
strategy without getting lost in the details by looking at month or year 
pages.  You can also tick of the day-by-day bite-size tasks without 
worrying about the overall strategy.  And finally, you know that your day 
tasks accurately reflect your goals for the week, month, and year, since 
you planned the high levels first and "trickled down" to the low levels. 
This has the nice side-effect that things which _seem_ important but 
_aren't_ important to achieve your goals never even make it into your day 
pages.

> I suspect that the best way to go in this direction would be to make 
> searching through tasks really efficient so that we dynamically create 
> the month, week and year views. However, going towards dynamically 
> generated views means there is no way to do some of the things I like 
> doing in Planner, like adding arbitrary text in between tasks...

Likewise... I think simplicity and flexibility are great virtues here, so 
that you can easily bend Planner to your will by inserting text wherever 
you want, for example.

> Not as elegant but far more doable with our current infrastructure
> would be to use planner-multi to associate each task and note with
> pages for the other time periods.

Yes, in fact this is what I'm doing for the time being.

> Month and week should be very doable, but a year can accumulate quite a 
> number of tasks and notes, so publishing this page may take a while.
> ...
> Scheduling things for a particular week can, say, schedule them onto 
> Monday and add a deadline for Sunday.

For what I want to do, at least, the Year page shouldn't take long to 
publish because it should contain _only_ information relevant to your 
high-level goals for the year.  Also, for what I envision the weekly goals 
shouldn't make it onto the day pages because the higher-level strategy 
would distract you from the nuts-and-bolts lower level tasks.  Or, at 
least it tends to distract me.

The upshot, it seems, is that there isn't a slick way to hack 
planner-date-regexp to do what I want.  So I'd imagine splitting 
planner-date-regexp into planner-date-regexp and planner-time-regexp, and 
then using planner-time-regexp for logical tests of whether a page refers 
to a time period, and then planner-date-regexp when the desired pages 
really do need to be days, either because the code then uses match-string 
to extract months and days, or because Planner wants a range of dates or 
something like that.

If I do this, what are the chances that the patch could be integrated into 
the main branch of the code?  Does the above seem reasonable?

Thanks,
Greg