>>>>> "SC" == Sacha Chua <[EMAIL PROTECTED]> writes:
SC> "Patricia J. Hawkins" <[EMAIL PROTECTED]> 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.
SC> Hmm... So non-master pages would contain references like {{:Task:1}}
SC> which means include task 1, whatever task 1 is. When Planner opens a
SC> page, it would update all such references with the task and a list of
SC> IDs.
SC> If we rewrite the task to make it plain text + reference, then we're
SC> back to the data-all-over-the-place problem.
No, not like that at all! As long as there's only one *master*, or
source for each task, you can make all the copies you want. This is a
distributed data problem. You just have to keep track of which single
item contains the original. So your reference just needs to indicate
whether this is *the* master or a copy, and you also want a variable
that points to the file/location that tracks all the master & copies.
so in OriginalProject you'd have {{:Task:1:m}}
and in GtdAtDesk you'd have {{:Task:1:c}}
and in GtdAllTasksByProject you'd have {{:Task:1:c}}
etc
In your planner-config.el you'd have
(setq planner-master-locator-file "~/.planner-locator"
and then in the master locator you'd have something like:
{{:Task:1}{Master:OriginalProject}{Copies:GtdAtDesk,GtdAllTasksByProject}}
or you might use the full pathname to the files, whatever works best
with planner's design.
In my thinking, if you modify one of the copies, say GtdAtDesk, planner
-- looks up the task in .planner-locator
-- updates the master
-- goes through the list of copies, and updates the copies.
If it can't find the master, it complains, and offers the user these
options:
Task nnn master file OriginalProject can't be found.
Enter the new location of OriginalProject
Or hit return to (make the just-edited file,) GtdAtDesk the tasks' new
master file
SC> If we make the reference read-only, invisible and intangible, and then
SC> use the display attribute to substitute the task description, we'd
SC> have text that isn't really "there". You won't be able to use your
SC> cursor keys or visit links, which makes a whole bucketload of useful
SC> Planner things useless... (This is the problem we have with the <lisp>
SC> tag.)
If *anything* I'm proposing interferes with a useful feature, it's
absolutely a bad design -- shoot it down now! *The data model should
not dictate the UI.*
(But in fact, I think my proposal would make planner a lot more robust
and flexible)
SC> Perhaps what we really want is the ability to associate multiple days
SC> with a task and have things make sense.
SC> Moving the page relationships out of the task line and putting it into
SC> a separate file would make adding new pages to the list easier,
SC> because we don't have to update and republish every page that's
SC> linked. People who publish HTML pages may want the task project pages
SC> included, but that can be looked up and arranged.
SC> Or we could use a separate file relating task IDs to dates, and let
SC> 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.
SC> Or fixing the old task?
Well, yes, but IRRC, it was wrong in a couple of places.
>> 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
SC> Hmmm. We'll need to define a nextrecfun for the sorting subroutines,
SC> modify planner-current-note-info, and change a few other things, but
SC> 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
SC> planner-id does the autoupdate for tasks. I suppose we could create a
SC> buffer-local variable containing the task list recognized when a page
SC> is loaded and it's easy to detect tasks that have been added or
SC> deleted, but we'd need to do something magical to detect tasks that
SC> have been modified. We may need to mess around with post-command-hook
SC> or something like that, and... err... I can't wrap my mind around
SC> something like that yet. Anyone up for a challenge? =) Get non-ID
SC> manual task editing to work? =)
What reasons are there for having non-ID tasks? Is it a feature? Do
ID'd tasks interfere with something people use? Or do people just not
turn it on because it's not required? Or because task IDs clutter
things up?
--
Patricia J. Hawkins
Hawkins Internet Applications
www.hawkinsia.com
_______________________________________________
emacs-wiki-discuss mailing list
emacs-wiki-discuss@nongnu.org
http://lists.nongnu.org/mailman/listinfo/emacs-wiki-discuss
