From: Carsten Dominik <carsten.dominik@gmail.com>
To: Bernt Hansen <bernt@norang.ca>
Cc: emacs-orgmode@gnu.org
Subject: Re: agenda bulk refile error
Date: Tue, 4 Aug 2009 22:46:43 +0200 [thread overview]
Message-ID: <7D30FB85-2620-49EC-A699-639D6EE6C134@gmail.com> (raw)
In-Reply-To: <874osntm86.fsf@gollum.intra.norang.ca>
Fixed, thanks.
- Carsten
On Aug 4, 2009, at 9:25 PM, Bernt Hansen wrote:
> 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 20:46 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
2009-08-04 20:46 ` Carsten Dominik [this message]
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=7D30FB85-2620-49EC-A699-639D6EE6C134@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=bernt@norang.ca \
--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).