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:
SC> Hello, Patricia! =)

>> One issue: Links to files are effectively keywords for tasks; in
>> order to create a new keyword, one has to create a new file. Files
>> proliferate over hell & gone -- and files also serve other
>> organizing purposes -- historic record, project groupings. Could we
>> divorce keywords from files? Or at least allow them to be links to
>> subheadings in files?

SC> Hmmmm. Let's see what needs to happen...

SC> - Creating a task: If we see a #ref, jump to that anchor and create
SC>   the task after that point. (Right after that point? One header later?)

SC> - Updating tasks: Make sure we keep the references. We match on task
SC>   description, anyway.

SC> - Editing tasks: Shouldn't be a problem. Just keep the references.

SC> - Deleting tasks: Shouldn't be a problem.

SC> Hey, you know, this seems doable...

:)

SC> Do we need to differentiate between tasks with identical descriptions
SC> in different sections? Identical tasks confuse us, anyway, so maybe we
SC> don't need to support that.

Or you just always use task ids.

>> Another issue: A basic rule of thumb in programming is that any one
>> piece of information or data comes from ONE location; it may be
>> copied elsewhere, but its ultimate, master value is stored in one
>> place only, and other copies regenerate themselves from that.

SC> The howm Emacs-based personal information manager does this, and it's
SC> pretty slick. One of the most confusing things for people is the fact
SC> that manual editing doesn't work for linked tasks unless you use the
SC> occasionally problematic planner-id.el module. I've thought about
SC> dynamically rebuilding pages, and planner-db.el has some preliminary
SC> support for that.

SC> It should be relatively easy to create a branch, rip out all the
SC> copying code, add code that rewrites the * Tasks section based on a
SC> central database, and rewrite the task modification code so that it
SC> works on the central database and then updates the copy.

SC> What do we do about manual editing? We could mark the generated page
SC> as read-only or give it special major-mode keys, like the way howm
SC> does it...

The point isn't that you want it all in one db; the point is, there is
only ONE designated master source for any one piece of information;
any other copies are copies.

I don't think you need to get rid of manual-editing -- just treat it
the same way you treat any database UI -- if the change makes it into
the master database, it's been entered; if it fails, well, them's the
breaks.  OR, the master location for a task is the page it's first
entered on -- you'd have to maintain a pointer to that in the main
DB. In some ways, that's more fragile, as the data goes away if you
delete the file, and you have to handle that contingency properly.
OTOH, if you have one central db, all your data goes away if you
delete your db.

Or even -- have a db which maintains task IDs, a pointer to each
task's master location, and a pointer to each of the copies.  The
master location could just be the most-recently user-edited copy of
the task; if the master location goes away (and the task hasn't simply
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> As for me, I've got some ingrained habits like manually typing
SC> one-page tasks in and adding blank lines to the tasks, and it's hard
SC> for me to visualize a dynamic interface that would fit those quirks.
SC> You might be better at doing that. =)

I think this is one of the great features of planner.  Note that
another programming rule of thumb is that your data architecture
should not dictate your UI.

>> At the moment, old day pages don't get updated -- which means that
>> tasks copied forward from old day pages can morph back to old

SC> What do you mean? =)

Well -- I haven't tracked this down thoroughly, but when I make a
 change to my day page templates & to planner-trunk functions, I
 recreate todays page by copying it to yesterday's page, & deleting
 today's page.  I was going nuts because an old version of a task
 (missing several xrefs) kept showing up, and a grep showed the old
 version was only in a 5-day-old day page; reducing
 planner-carry-tasks-forward to 4 eliminated the problem.

>> versions. This can be fixed -- and the next similar issue can be
>> fixed -- and the next one. Sacha and others, how much time do you
>> put in fixing or changing propagation problems?

SC> I use functions, which tend to keep things pretty consistent.
SC> planner-edit-task-description, planner-update-note,
SC> planner-copy-or-move-task, planner-replan-task... I just have all of
SC> them bound to shortcut keys somewhere. We should look into making this
SC> easier for people, or at least warn them up front... =)

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
".#1"; same for notes (these are examples, not regexps).  User
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
file is recovered from a trashed session, all the tasks and notes get
updated.

What do you think?

-- 
Patricia J. Hawkins
Hawkins Internet Applications
www.hawkinsia.com