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: Sat, 06 Aug 2005 22:19:57 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

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

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?

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

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

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

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

- Deleting tasks: Shouldn't be a problem.

Hey, you know, this seems doable...

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

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

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

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

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

As for me, I've got some ingrained habits like manually typing
one-page tasks in and adding blank lines to the tasks, and it's hard
for me to visualize a dynamic interface that would fit those quirks.
You might be better at doing that. =)

> 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

What do you mean? =)

> 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?

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