Refiling goes to the wrong place

Refiling goes to the wrong place

[Bernt Hansen]

Hi Carsten,

I thought I should mention this sooner rather than later to postpone any
up-coming release you might be thinking about :)  I'm assuming this is
an org-mode bug and not some inconsistency in my setup but that's not
proven yet.

I have an issue with refile going to the wrong place fairly
consistently.  I'm not sure how long this has been going on.  I'll try
to isolate a test case for this.

I have a note I want to refile

,----[ refile.org ]
| * org-mode-lisp table function for column values :NOTE:
`----

which is org-mode related from a recent article on this list and when I
refile to 'Research org-mode (norang.org)' it ends up in the right tree
but under the wrong task.  I'm refiling a note called 'org-mode lisp
table function for column values' (ie. the last time I refiled the note
it ended up under 'Research Website Security' instead of the right
place.

,----[ norang.org ]
| * Research...
| ** Research Website Security
| *** org-mode-lisp table function for column values :NOTE:
`----

I've been using undo after the refile to put it back in the refile.org
buffer and removing it from the norang.org buffer then redoing the
refile operation.

I recently switched my org-refile to try out direct ido refiling and
noticed this problem after that change.  I used to file in steps from
file.org/level1task/level2task etc and now I'm trying to file directly
in one step to see if that's faster.

So far it seems to do things wrong when the target tree is folded (or
partially revealed) but sometimes it gets it right.  It's one of your
favourite types of bugs ;)

My target tree looks like this:

,----[ norang.org ]
| * Research
|   :PROPERTIES:...
| ** TODO Research Rails...
| ** TODO Research Java...
| ** TODO Research .NET...
| ** TODO Research GCC and C++...
| ** TODO Research Accounting Packages...
| ** TODO Research Tools...
| ** TODO Research Object Oriented Design...
| ** TODO Research org-mode...
| ** TODO Research VPN in Linux...
| ** TODO Research Website Security...
| ** TODO Research CSS...
| ** TODO Research Emacs...
| ...
`----

-Bernt

Org-mode version 6.29trans (release_6.29c.86.gfa36)
GNU Emacs 22.2.1 (i486-pc-linux-gnu, GTK+ Version 2.12.11) of 2008-11-09 on raven, modified by Debian

Re: Refiling goes to the wrong place

[Benjamin Andresen]

Hey,

Bernt Hansen <bernt@norang.ca> writes:

> [snip]

I have the same behavior from time to time. But whenever I try to find a
reproducible scenario it disappears.

It also never happens twice in a row, same as with Bernt.

br,
benny

Re: Refiling goes to the wrong place

[Bernt Hansen]

Benjamin Andresen <benny@in-ulm.de> writes:

> I have the same behavior from time to time. But whenever I try to find a
> reproducible scenario it disappears.
>
> It also never happens twice in a row, same as with Bernt.

I think I have something that is reproducible.

,----[ /tmp/x.org ]
| 
| * Refile Targets
| ** TODO One
| ** TODO Two
| ** TODO Three
| ** TODO Four
| ** TODO Five
| ** TODO Six
| *** TODO Six.one
| *** TODO Six.two
| **** TODO Clock me
| ** TODO Seven
| ** TODO Eight
| ** TODO Nine
| ** TODO Ten
| * Refile Tasks
| *** TODO Refile Me
`----

,----[ /tmp/minimal.emacs ]
| (add-to-list 'load-path (expand-file-name "~/git/org-mode/lisp"))
| (add-to-list 'auto-mode-alist '("\\.\\(org\\|org_archive\\|txt\\)$" . org-mode))
| (require 'org-install)
| 
| (global-set-key "\C-cl" 'org-store-link)
| (global-set-key "\C-ca" 'org-agenda)
| (global-set-key "\C-cb" 'org-iswitchb)
| 
| (setq org-log-done (quote time))
| (setq org-log-into-drawer t)
| (setq org-agenda-files '("/tmp/x.org"))
| (setq user-init-file "/tmp/custom.el")
| 
| (setq org-refile-allow-creating-parent-nodes nil)
| (setq org-refile-targets (quote ((nil :maxlevel . 2) (org-agenda-files :maxlevel . 2))))
| (setq org-refile-use-outline-path nil)
| (setq org-todo-keywords (quote ((sequence "TODO(t!)" "STARTED(s!)" "|" "DONE(d!/!)") (sequence "WAITING(w@/!)" "SOMEDAY(S!)" "OPEN(O@)" "|" "CANCELLED(c@/!)") (sequence "QUOTE(q!)" "QUOTED(Q!)" "|" "APPROVED(A@)" "EXPIRED(E@)" "REJECTED(R@)"))))
`----

Steps to reproduce:
 
  1. Save the files /tmp/x.org and /tmp/minimal.emacs
  2. emacs -q -l /tmp/minimal.emacs /tmp/x.org
  3. Go to CONTENTS view with S-TAB twice
  4. Put point on **** TODO Clock Me
  5. Clock in the task with C-c C-x C-i

     This adds a logbook drawer with the clock

  6. Fold to OVERVIEW view with S-TAB

     So it looks like this

     ,----[ x.org folder ]
     | 
     | * Refile Targets...
     | * Refile Tasks...
     `----

  7. M-x org-clock-goto

     This reveals the buffer like so:

     ,----
     | 
     | * Refile Targets...
     | **** TODO Clock me
     |      :LOGBOOK:...
     | ...
     | * Refile Tasks...
     `----

     I think this is the critical step.

  8. Put point on Refile Tasks
  9. Show task to refile with TAB
  10. Put point on ** TODO Refile Me
  11. Refile to Ten with C-c C-w Ten RET
  12. Put point on Refile Me
  13. Reveal with C-c C-r

      Shows that we are under TODO Ten.  So far so good

      ,----
      | 
      | * Refile Targets...
      | **** TODO Clock me
      |      :LOGBOOK:...
      | ...
      | ** TODO Ten
      | *** TODO Refile Me
      | * Refile Tasks
      `----

  14. Now repeat steps 10-13 but refile to 'Two' instead of 'Ten'

      This goes to the wrong place.  This files under Nine for me

      ,----
      | 
      | * Refile Targets...
      | **** TODO Clock me
      |      :LOGBOOK:...
      | ...
      | ** TODO Nine
      | *** TODO Refile Me
      | ** TODO Ten
      | * Refile Tasks
      `----

  15. Repeat steps 10-13 with refiling to 'Two' each time

      This moves Refile Me up one task at a time until it gets to Two
      ie. it refiles to Eight, then Seven, then Six, then Five, then
      Four then Three, then Two.      

If you show contents view with S-TAB and then refile it goes to the
right place immediately.  So this definitely has something to do with
the folded view of the org file.

I'll be _really_ happy when Carsten squashes this bug :)

-Bernt

Re: Refiling goes to the wrong place

[Bernt Hansen]

Bernt Hansen <bernt@norang.ca> writes:

> ,----[ /tmp/x.org ]
> | 
> | * Refile Targets...
> | * Refile Tasks
> | *** TODO Refile Me
> `----

The task 'TODO Refile Me' should only have 2 leading stars.  This was a
cut/paste error on my part.

-Bernt

Re: Re: Refiling goes to the wrong place

[Nick Dokos]

Bernt Hansen <bernt@norang.ca> wrote:

> I think I have something that is reproducible.
> 
...reproduction case elided...
> 
> I'll be _really_ happy when Carsten squashes this bug :)
> 

Wow! I just *had* to try it for myself: works exactly as you describe.

Nick

Re: Re: Refiling goes to the wrong place

[Carsten Dominik]

On Aug 27, 2009, at 8:33 PM, Bernt Hansen wrote:

[long description omitted]

>
> I'll be _really_ happy when Carsten squashes this bug :)

Well, in that case I wish you a happy day.  Lets hope that his was
the same bug that others have seen.

Thank you *very* much for your persistence and the unsurpassed clarity
of your reports - it took a mere 5 minutes to find the problem.

For those who are interested:  The cause was the outline function
outline-get-next-sibling which does only find visible siblings.
By creating an inconsistent outline state using the org-clock-goto
function, Bernt created a visible sibling among invisible ones.
This was at least part of the problem.  I hope it is fixed now.
At least, Bernt's example works now correctly.

- Carsten

Re: Re: Refiling goes to the wrong place

[Bernt Hansen]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On Aug 27, 2009, at 8:33 PM, Bernt Hansen wrote:
>
> [long description omitted]
>
>>
>> I'll be _really_ happy when Carsten squashes this bug :)
>
> Well, in that case I wish you a happy day.  Lets hope that his was
> the same bug that others have seen.
>
> Thank you *very* much for your persistence and the unsurpassed clarity
> of your reports - it took a mere 5 minutes to find the problem.
>
> For those who are interested:  The cause was the outline function
> outline-get-next-sibling which does only find visible siblings.
> By creating an inconsistent outline state using the org-clock-goto
> function, Bernt created a visible sibling among invisible ones.
> This was at least part of the problem.  I hope it is fixed now.
> At least, Bernt's example works now correctly.

:)

* Bernt does the happy dance \o/

Hopefully this is related to the agenda navigation (RET/TAB on an agenda
item) goes to the wrong place issue we've seen in the past.

I got lucky yesterday and stumbled across a case that triggered this bug
more than once in my org files.  I think we've been chasing this beast
for over a year.

Thanks again!!!

-Bernt

Re: Re: Refiling goes to the wrong place

[Carsten Dominik]

On Aug 28, 2009, at 2:09 PM, Bernt Hansen wrote:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> On Aug 27, 2009, at 8:33 PM, Bernt Hansen wrote:
>>
>> [long description omitted]
>>
>>>
>>> I'll be _really_ happy when Carsten squashes this bug :)
>>
>> Well, in that case I wish you a happy day.  Lets hope that his was
>> the same bug that others have seen.
>>
>> Thank you *very* much for your persistence and the unsurpassed  
>> clarity
>> of your reports - it took a mere 5 minutes to find the problem.
>>
>> For those who are interested:  The cause was the outline function
>> outline-get-next-sibling which does only find visible siblings.
>> By creating an inconsistent outline state using the org-clock-goto
>> function, Bernt created a visible sibling among invisible ones.
>> This was at least part of the problem.  I hope it is fixed now.
>> At least, Bernt's example works now correctly.
>
> :)
>
> * Bernt does the happy dance \o/
>
> Hopefully this is related to the agenda navigation (RET/TAB on an  
> agenda
> item) goes to the wrong place issue we've seen in the past.

I don't think this is related, unfortunately, because this was  
specific for refiling ...

:-(
- Carsten

>
> I got lucky yesterday and stumbled across a case that triggered this  
> bug
> more than once in my org files.  I think we've been chasing this beast
> for over a year.
>
> Thanks again!!!
>
> -Bernt

Re: Re: Refiling goes to the wrong place

[Bernt Hansen]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On Aug 28, 2009, at 2:09 PM, Bernt Hansen wrote:
>
>> Hopefully this is related to the agenda navigation (RET/TAB on an
>> agenda
>> item) goes to the wrong place issue we've seen in the past.
>
> I don't think this is related, unfortunately, because this was
> specific for refiling ...
>
> :-(

Oh well... we'll nail that one again later then.

:)

-Bernt