Hello, 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. Regards, -- Nicolas Goaziou 0x80A93738
