Bug: return key does not show the subtree the first time on a newly opened org file

Bug: return key does not show the subtree the first time on a newly opened org file

[Wanrong Lin]

Hi,

I have the following in my org-mode configuration:

(setq org-return-follows-link t)

Also, by default my org files are in overview mode (folded) when opened.

Usually, if my cursor is at the beginning of a heading, I can use the 
return key to cycle the visibility of its subtree. However, this does 
not work when I open an org file and do it the first time (the return 
key will just insert a blank line before the heading). But after the 
first time, it works fine again.

Thanks a lot for looking into this.

Wanrong

Re: Bug: return key does not show the subtree the first time on a newly opened org file

[Wanrong Lin]

Forgot to mention this:

To reproduce the bug, after opening an org file, don't do anything 
(don't even move the cursor),  just press the return key. I use 
"session.el", so when I open an org file, the cursor will go to the the 
position of my last change in the buffer, and I can arrange the point to 
be on a heading. If you don't use "session.el", here is another way to 
reproduce the bug:

Open a test org file "test.org" and put the following into it,

* TODO A 
Test                                                             :mytag:
  SCHEDULED: <2008-02-27 Wed>

*Close* the file, do a tag search on "mytag", in the search result  
press  "TAB"  key to jump to the "TODO A Test" heading, which should be 
folded. Press return key and you will see the failure. Do it again and 
it works.

Wanrong

Wanrong Lin wrote:
> Hi,
>
> I have the following in my org-mode configuration:
>
> (setq org-return-follows-link t)
>
> Also, by default my org files are in overview mode (folded) when opened.
>
> Usually, if my cursor is at the beginning of a heading, I can use the 
> return key to cycle the visibility of its subtree. However, this does 
> not work when I open an org file and do it the first time (the return 
> key will just insert a blank line before the heading). But after the 
> first time, it works fine again.
>
> Thanks a lot for looking into this.
>
> Wanrong
>
>
>
>

Re: Bug: return key does not show the subtree the first time on a newly opened org file

[Bastien]

Wanrong Lin <wanrong.lin@gmail.com> writes:

> I have the following in my org-mode configuration:
>
> (setq org-return-follows-link t)

This is about following links, no (un)folding subtrees...

> Usually, if my cursor is at the beginning of a heading, I can use the
> return key to cycle the visibility of its subtree. 

AFAIK, <RET> doesn't (un)fold a subtree.  Maybe you mean the <TAB> key?
I guess I'm missing something...

-- 
Bastien

Re: Bug: return key does not show the subtree the first time on a newly opened org file

[Wanrong Lin]

Bastien wrote:
> Wanrong Lin <wanrong.lin@gmail.com> writes:
>
>   
>> I have the following in my org-mode configuration:
>>
>> (setq org-return-follows-link t)
>>     
>
> This is about following links, no (un)folding subtrees...
>
>   
Yes, but only with this setting will <return> key be added to the 
"org-mouse-map" key map, and be bound to "org-open-at-point" command 
under certain contexts (like on the leading stars of a heading). 
Further, "org-open-at-point" is advised by org-mouse.el, which will do 
"org-cycle" under certain contexts.
>> Usually, if my cursor is at the beginning of a heading, I can use the
>> return key to cycle the visibility of its subtree. 
>>     
>
> AFAIK, <RET> doesn't (un)fold a subtree.  Maybe you mean the <TAB> key?
> I guess I'm missing something...
>
>   
I did meant return key. See my comments above.

Thanks for your comments.

Wanrong

Re: Bug: return key does not show the subtree the first time on a newly opened org file

[Carsten Dominik]

On Feb 28, 2008, at 3:16 AM, Wanrong Lin wrote:

> Bastien wrote:
>> Wanrong Lin <wanrong.lin@gmail.com> writes:
>>
>>
>>> I have the following in my org-mode configuration:
>>>
>>> (setq org-return-follows-link t)
>>>
>>
>> This is about following links, no (un)folding subtrees...
>>
>>
> Yes, but only with this setting will <return> key be added to the  
> "org-mouse-map" key map, and be bound to "org-open-at-point" command  
> under certain contexts (like on the leading stars of a heading).  
> Further, "org-open-at-point" is advised by org-mouse.el, which will  
> do "org-cycle" under certain contexts.

Yes, this is really an accidental feature by a sequence of events:

org-return-follow-link will add org-return to the mouse-map
org-mouse.el will activate the stars in a headline

I can reproduce the bug, but I have no idea what is causing this, it  
must be
something in the internal setup of Emacs keymaps in a new buffer,
I have no idea how to fix this or work around it.

Why in the world would you use RET for cycling instead of TAB?

- Carsten

>
>>> Usually, if my cursor is at the beginning of a heading, I can use  
>>> the
>>> return key to cycle the visibility of its subtree.
>>
>> AFAIK, <RET> doesn't (un)fold a subtree.  Maybe you mean the <TAB>  
>> key?
>> I guess I'm missing something...
>>
>>
> I did meant return key. See my comments above.
>
> Thanks for your comments.
>
> Wanrong
>
>
> _______________________________________________
> 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

Re: Bug: return key does not show the subtree the first time on a newly opened org file

[Bastien Guerry]

Carsten Dominik <dominik@science.uva.nl> writes:

>> Yes, but only with this setting will <return> key be added to the
>> "org-mouse-map" key map, and be bound to "org-open-at-point" command
>> under certain contexts (like on the leading stars of a heading).
>> Further, "org-open-at-point" is advised by org-mouse.el, which will
>> do "org-cycle" under certain contexts.
>
> Yes, this is really an accidental feature by a sequence of events:
>
> org-return-follow-link will add org-return to the mouse-map
> org-mouse.el will activate the stars in a headline

Yes, there is an advice for this in org-mouse.el.  

I think we should remove it since org-mouse.el shouldn't change the
behavior of keystrokes (only the behavior of the mouse.)

-- 
Bastien

Re: Bug: return key does not show the subtree the first time on a newly opened org file

[Wanrong Lin]

Bastien Guerry wrote:
> Carsten Dominik <dominik@science.uva.nl> writes:
>
>   
>>> Yes, but only with this setting will <return> key be added to the
>>> "org-mouse-map" key map, and be bound to "org-open-at-point" command
>>> under certain contexts (like on the leading stars of a heading).
>>> Further, "org-open-at-point" is advised by org-mouse.el, which will
>>> do "org-cycle" under certain contexts.
>>>       
>> Yes, this is really an accidental feature by a sequence of events:
>>
>> org-return-follow-link will add org-return to the mouse-map
>> org-mouse.el will activate the stars in a headline
>>     
>
> Yes, there is an advice for this in org-mouse.el.  
>
> I think we should remove it since org-mouse.el shouldn't change the
> behavior of keystrokes (only the behavior of the mouse.)
>
>   
That probably is true. But I have doubt that removing the advice itself 
and bind the key in some other place will really solve the problem. To 
me, it seems somehow the first time you open a org-file, some context is 
not recognized correctly and hence the key map is not activated. If I 
just execute a command, any command (like "C-g" which does nothing), and 
then press the return key, it will work. Is that puzzling? :-)

Wanrong

Re: Bug: return key does not show the subtree the first time on a newly opened org file

[Bastien Guerry]

Wanrong Lin <wanrong.lin@gmail.com> writes:

> Bastien Guerry wrote:
>>
>> Yes, there is an advice for this in org-mouse.el.  
>>
>> I think we should remove it since org-mouse.el shouldn't change the
>> behavior of keystrokes (only the behavior of the mouse.)
>>   
> That probably is true. But I have doubt that removing the advice itself
> and bind the key in some other place will really solve the problem. To
> me, it seems somehow the first time you open a org-file, some context is
> not recognized correctly and hence the key map is not activated. If I
> just execute a command, any command (like "C-g" which does nothing), and
> then press the return key, it will work. Is that puzzling? :-)

It *is* puzzling.  

I have a fix for this.  I'm testing it a few days more and will commit
it if it works okay.

-- 
Bastien

Re: Bug: return key does not show the subtree the first time on a newly opened org file

[Wanrong Lin]

> It *is* puzzling.  
>
> I have a fix for this.  I'm testing it a few days more and will commit
> it if it works okay.
>
>   
Look forward to it. Although I am trying to get into the habit of using 
TAB, it won't hurt to have the old way working too. Thanks a lot.

Wanrong

Re: Bug: return key does not show the subtree the first time on a newly opened org file

[Wanrong Lin]

> Yes, this is really an accidental feature by a sequence of events:
>
> org-return-follow-link will add org-return to the mouse-map
> org-mouse.el will activate the stars in a headline
>
> I can reproduce the bug, but I have no idea what is causing this, it 
> must be
> something in the internal setup of Emacs keymaps in a new buffer,
> I have no idea how to fix this or work around it.
>
> Why in the world would you use RET for cycling instead of TAB?
>
> - Carsten
Because I discovered it and thought that was an official feature and got 
used to it from day 1. :-) I will try to use Tab from now on.

Wanrong