* agenda bulk refile error
@ 2009-08-04 18:00 Bernt Hansen
2009-08-04 19:12 ` Carsten Dominik
0 siblings, 1 reply; 5+ messages in thread
From: Bernt Hansen @ 2009-08-04 18:00 UTC (permalink / raw
To: emacs-orgmode
Every so often I run into a situation where bulk refiling doesn't work
anymore.
I currently have 15 items in my refile.org file that I want to refile to
other locations. I marked a few of them and bulk refiled them just
fine. Then I marked a few more and B r fails with "Cannot find entry
for marker #<marker at 297156 in norang.org>"
I think this happens when I mark multiple tasks in the same subtree
(i.e. the parent and a sibling) and refile both to the same location.
After that it gets confused.
If I have a task like this in refile.org
#+FILETAGS: REFILE
* Test
** Test 2
and run a tags match on REFILE I see both tasks. Mark both with m in
the agenda and B r to some other location. It refiles the first (and
this moves the sibling too) and then it's broken after that.
I get the following backtrace
Debugger entered--Lisp error: (error "Cannot find entry for marker #<marker at 297156 in norang.org>")
signal(error ("Cannot find entry for marker #<marker at 297156 in norang.org>"))
error("Cannot find entry for marker %s" #<marker at 297156 in norang.org>)
(or (text-property-any (point-min) (point-max) (quote org-hd-marker) e) (error "Cannot find entry for marker %s" e))
(goto-char (or (text-property-any ... ... ... e) (error "Cannot find entry for marker %s" e)))
(while (setq e (pop entries)) (goto-char (or ... ...)) (eval cmd) (setq org-agenda-bulk-marked-entries (delete e org-agenda-bulk-marked-entries)) (setq cnt (1+ cnt)))
(let* ((action ...) (entries ...) cmd rfloc state e tag (cnt 0)) (cond (... ...) (... ...) (... ... ... ...) (... ... ...) (... ... ...) (... ...) (t ...)) (while (setq e ...) (goto-char ...) (eval cmd) (setq org-agenda-bulk-marked-entries ...) (setq cnt ...)) (setq org-agenda-bulk-marked-entries nil) (org-agenda-bulk-remove-all-marks) (message "Acted on %d entries" cnt))
org-agenda-bulk-action()
call-interactively(org-agenda-bulk-action)
I've since changed my refile custom view to only show level 1 tasks to
avoid this problem.
-Bernt
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: agenda bulk refile error
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
0 siblings, 1 reply; 5+ messages in thread
From: Carsten Dominik @ 2009-08-04 19:12 UTC (permalink / raw
To: Bernt Hansen; +Cc: emacs-orgmode
Hi Bernt,
what would be the *wanted* result of marking both a parent and its
child, and then refiling both?
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.
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. 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. 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.
- Carsten
On Aug 4, 2009, at 8:00 PM, Bernt Hansen wrote:
> Every so often I run into a situation where bulk refiling doesn't work
> anymore.
>
> I currently have 15 items in my refile.org file that I want to
> refile to
> other locations. I marked a few of them and bulk refiled them just
> fine. Then I marked a few more and B r fails with "Cannot find entry
> for marker #<marker at 297156 in norang.org>"
>
> I think this happens when I mark multiple tasks in the same subtree
> (i.e. the parent and a sibling) and refile both to the same location.
> After that it gets confused.
>
> If I have a task like this in refile.org
>
> #+FILETAGS: REFILE
> * Test
> ** Test 2
>
> and run a tags match on REFILE I see both tasks. Mark both with m in
> the agenda and B r to some other location. It refiles the first (and
> this moves the sibling too) and then it's broken after that.
>
> I get the following backtrace
>
> Debugger entered--Lisp error: (error "Cannot find entry for marker
> #<marker at 297156 in norang.org>")
> signal(error ("Cannot find entry for marker #<marker at 297156 in
> norang.org>"))
> error("Cannot find entry for marker %s" #<marker at 297156 in
> norang.org>)
> (or (text-property-any (point-min) (point-max) (quote org-hd-
> marker) e) (error "Cannot find entry for marker %s" e))
> (goto-char (or (text-property-any ... ... ... e) (error "Cannot
> find entry for marker %s" e)))
> (while (setq e (pop entries)) (goto-char (or ... ...)) (eval cmd)
> (setq org-agenda-bulk-marked-entries (delete e org-agenda-bulk-
> marked-entries)) (setq cnt (1+ cnt)))
> (let* ((action ...) (entries ...) cmd rfloc state e tag (cnt 0))
> (cond (... ...) (... ...) (... ... ... ...) (... ... ...)
> (... ... ...) (... ...) (t ...)) (while (setq e ...) (goto-char ...)
> (eval cmd) (setq org-agenda-bulk-marked-entries ...) (setq cnt ...))
> (setq org-agenda-bulk-marked-entries nil) (org-agenda-bulk-remove-
> all-marks) (message "Acted on %d entries" cnt))
> org-agenda-bulk-action()
> call-interactively(org-agenda-bulk-action)
>
> I've since changed my refile custom view to only show level 1 tasks to
> avoid this problem.
>
> -Bernt
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: agenda bulk refile error
2009-08-04 19:12 ` Carsten Dominik
@ 2009-08-04 19:25 ` Bernt Hansen
2009-08-04 20:46 ` Carsten Dominik
0 siblings, 1 reply; 5+ messages in thread
From: Bernt Hansen @ 2009-08-04 19:25 UTC (permalink / raw
To: Carsten Dominik; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: agenda bulk refile error
2009-08-04 19:25 ` Bernt Hansen
@ 2009-08-04 20:46 ` Carsten Dominik
2009-08-04 20:54 ` Bernt Hansen
0 siblings, 1 reply; 5+ messages in thread
From: Carsten Dominik @ 2009-08-04 20:46 UTC (permalink / raw
To: Bernt Hansen; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: agenda bulk refile error
2009-08-04 20:46 ` Carsten Dominik
@ 2009-08-04 20:54 ` Bernt Hansen
0 siblings, 0 replies; 5+ messages in thread
From: Bernt Hansen @ 2009-08-04 20:54 UTC (permalink / raw
To: Carsten Dominik; +Cc: emacs-orgmode
Carsten Dominik <carsten.dominik@gmail.com> writes:
> Fixed, thanks.
Thanks!
-Bernt
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-08-04 20:54 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2009-08-04 20:54 ` Bernt Hansen
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.