Re: [O] Basic visibility cycling bug in 8.3.6

[Nicolas Goaziou]

Hello,

Marcus Zibrowius <address@hidden> writes:

Cc'ing to the list for further discussion.

> Excellent!   Thanks a lot for helping so quickly.  I still maintain that
> the behaviour is different for me in org-mode 7.9.3, but I understand
> now that it's a (new?) feature rather than a bug.

I misread your version string. The behaviour you describe doesn't happen
in Org 7.9.3f, but was introduced in
2efbd0f138180fe14773d5485ad3c59332d6ddb3, i.e., between Org 7.9.3f and
and Org 7.9.4. I can indeed observe the same with the latter.

However this change never made it into the following release, i.e., Org
8.0. You're observing a very short-lived feature.

> Let me reiterate what I think is different , now that I understand
> better what is happening:  in org-mode 8.3.6, if I start with 
>
> * a
> ** b
> ** c
> ** d
> ** e
> ** f
> ** g
> ** h
>
> with point at e, then if I collapse with Shift+TAB and reexpand with
> TAB, I get only:
>
> * a...
> ** e
> ...
>
> with point at the beginning of the line **e, and I can reexpand the
> whole tree with C-c C-r.   So the line in which point was is somehow
> remembered.  In contrast, Shift+TAB followed by TAB in org-mode 7.9.3f
> (details below) brings back the whole tree directly, but forgets where
> point was:  point ends up just right of a.

I think it is important to preserve point when cycling view. It would be
surprising if a function modifying visibility also moved it. Besides,
this is useful when one wants to have a glimpse to the overview (S-TAB)
and go back to the editing location (another S-TAB) immediatly after.

I have no strong opinion on what should be displayed when pressing TAB
in this case, tho. It seems the implentation of `org-cycle' sort of
decided for us, i.e., it wasn't meant to handle this situation.

Regards,

-- 
Nicolas Goaziou                                                0x80A93738