Marcus Zibrowius <marcus.zibrow...@hhu.de> 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.
Nicolas Goaziou 0x80A93738