Re: [emacs-wiki-discuss] Re: Planner data design, was Re: planner: why "move" tasks instead of copy?

[Patricia J. Hawkins]

>>>>> "SC" == Sacha Chua <address@hidden> writes:

SC> "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.

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