From: Bernt Hansen <bernt@norang.ca>
To: Carsten Dominik <carsten.dominik@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: agenda bulk refile error
Date: Tue, 04 Aug 2009 15:25:45 -0400 [thread overview]
Message-ID: <874osntm86.fsf@gollum.intra.norang.ca> (raw)
In-Reply-To: <F57E865F-CE83-4271-9495-52A0EAA2E3C1@gmail.com> (Carsten Dominik's message of "Tue\, 4 Aug 2009 21\:12\:56 +0200")
Carsten Dominik <carsten.dominik@gmail.com> 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
next prev parent reply other threads:[~2009-08-04 19:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-04 18:00 agenda bulk refile error Bernt Hansen
2009-08-04 19:12 ` Carsten Dominik
2009-08-04 19:25 ` Bernt Hansen [this message]
2009-08-04 20:46 ` Carsten Dominik
2009-08-04 20:54 ` Bernt Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874osntm86.fsf@gollum.intra.norang.ca \
--to=bernt@norang.ca \
--cc=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).