emacs-wiki-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[emacs-wiki-discuss] Re: Planner data design, was Re: planner: why "move


From: Sacha Chua
Subject: [emacs-wiki-discuss] Re: Planner data design, was Re: planner: why "move" tasks instead of copy?
Date: Sun, 07 Aug 2005 19:53:29 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

"Patricia J. Hawkins" <address@hidden> writes:

> been deleted), planner asks if it should delete all the copies, or
> designate one of the copies (default, a copy that's in the file with
> most recent time stamp) as the new master location.

Hmm... So non-master pages would contain references like {{:Task:1}}
which means include task 1, whatever task 1 is. When Planner opens a
page, it would update all such references with the task and a list of
IDs.

If we rewrite the task to make it plain text + reference, then we're
back to the data-all-over-the-place problem.

If we make the reference read-only, invisible and intangible, and then
use the display attribute to substitute the task description, we'd
have text that isn't really "there". You won't be able to use your
cursor keys or visit links, which makes a whole bucketload of useful
Planner things useless... (This is the problem we have with the <lisp>
tag.)

Perhaps what we really want is the ability to associate multiple days
with a task and have things make sense.

Moving the page relationships out of the task line and putting it into
a separate file would make adding new pages to the list easier,
because we don't have to update and republish every page that's
linked. People who publish HTML pages may want the task project pages
included, but that can be looked up and arranged.

Or we could use a separate file relating task IDs to dates, and let
each task have a list of plan pages as usual... Hmm. That might work.

>  version was only in a 5-day-old day page; reducing
>  planner-carry-tasks-forward to 4 eliminated the problem.

Or fixing the old task?

> Yes, this should be really transparent.  How about this -- define a
> task as containing everything from the "#B _ " string through the
> start of: the next "#B..." string or the next "** " string or the next

Hmmm. We'll need to define a nextrecfun for the sorting subroutines,
modify planner-current-note-info, and change a few other things, but
this might be doable.

> customizable, of course.  When the user edits a Planner page, track
> where the tasks & notes begin and end, and which task or note the user
> is in.  When the file is saved, those tasks & notes get updated; if a

planner-id does the autoupdate for tasks. I suppose we could create a
buffer-local variable containing the task list recognized when a page
is loaded and it's easy to detect tasks that have been added or
deleted, but we'd need to do something magical to detect tasks that
have been modified. We may need to mess around with post-command-hook
or something like that, and... err... I can't wrap my mind around
something like that yet. Anyone up for a challenge? =) Get non-ID
manual task editing to work? =)

-- 
Sacha Chua <address@hidden> - open source geekette
http://sacha.free.net.ph/ - PGP Key ID: 0xE7FDF77C
interests: emacs, gnu/linux, personal information management, juggling
sachac on irc.freenode.net#emacs . YM: sachachua83




reply via email to

[Prev in Thread] Current Thread [Next in Thread]