From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: agenda bulk refile error Date: Tue, 4 Aug 2009 22:46:43 +0200 Message-ID: <7D30FB85-2620-49EC-A699-639D6EE6C134@gmail.com> References: <878whztq6x.fsf@gollum.intra.norang.ca> <874osntm86.fsf@gollum.intra.norang.ca> Mime-Version: 1.0 (Apple Message framework v935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MYQuN-00010f-Ci for emacs-orgmode@gnu.org; Tue, 04 Aug 2009 16:46:55 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MYQuI-0000xl-EZ for emacs-orgmode@gnu.org; Tue, 04 Aug 2009 16:46:54 -0400 Received: from [199.232.76.173] (port=57656 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MYQuI-0000xe-7D for emacs-orgmode@gnu.org; Tue, 04 Aug 2009 16:46:50 -0400 Received: from mail-ew0-f211.google.com ([209.85.219.211]:45726) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MYQuH-0002v5-FT for emacs-orgmode@gnu.org; Tue, 04 Aug 2009 16:46:49 -0400 Received: by ewy7 with SMTP id 7so1009893ewy.42 for ; Tue, 04 Aug 2009 13:46:48 -0700 (PDT) In-Reply-To: <874osntm86.fsf@gollum.intra.norang.ca> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Bernt Hansen Cc: emacs-orgmode@gnu.org Fixed, thanks. - Carsten On Aug 4, 2009, at 9:25 PM, Bernt Hansen wrote: > Carsten Dominik 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