Carsten Dominik <address@hidden> writes:
Hi Bernt,
what would be the *wanted* result of marking both a parent and its
child, and then refiling both?
I'd want the parent refiled and the child to follow normally and still
have the same parent as it did before refiling. It's really a mistake
(for me) to try to refile both and the agenda view I was looking at
didn't obviously show that this was a child of this other task I was
refiling already in the same operation. I was just picking off tasks
and moving them to the right file and level 1 category.
I guess the problem happens when you first refile the parent, and
then
the child. The reason for this is that, when an entry is refiled
from
the agenda, all entries in the agenda that stem from the subtree of
this item will be removed from the agenda. This is the right ting to
do, but of course it causes problems if you have marked both a parent
and one of it's children.
Yes it works the way I want it to now (refiling the parent with the
children -- and then the child task that was also selected is *gone*
which probably is the cause of this error message.)
Would it be acceptable that first the child gets refiled, and then
the
parent? If yes, a simple solution would be to sort the task markers
by buffer position before doing te bulk command.
No that isn't the behaviour I was looking for. I just want to refile
the parent to get it out of the refile.org file (the child would
automatically go with it and preserve it's location in the parent
subtree)
However, it seems to me that the right course of action would be to
move the parent with its subtree, and to ignore the mark on the
child.
That's better :) The child was refiled due to the parent task being
refiled so just ignore the mark. You might run into problems if the
agenda tasks are sorted so that the child is before the parent -- then
you'll refile the child first, and the parent after which would
modified
the tree.
We could, instead of throwing an error, prompt the user about how to
proceed. Of set a variable that such errors should simply be
ignored.
I'm not sure that's worth it. I think keeping deterministic behaviour
is easiest to understand and document. If you select a parent and
refile all children go with it. If you really want to extract a child
from the parent then it should be two separate refile operations - the
first to move the child out of the parent's tree, and the second to
move
the parent tree.
If it's possible to just ignore marks on child tasks when a parent is
selected I think that will work better - this leaves a deterministic
result -- the order of tasks in the agenda will not affect the result
after refiling. If you refile a parent then all children stay as in
that tree and move with the parent.
Hopefully that makes sense :)
-Bernt