* 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.