Re: [O] Basic visibility cycling bug in 8.3.6
Hello, Marcus Zibrowius 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 Goaziou0x80A93738
Re: [O] Basic visibility cycling bug in 8.3.6
Hello, Marcus Zibrowius writes: > In this version, visibility cycling does not work as expected. Consider > the following three-line example file: > > * a > ** b > ** c > > Consider the following sequence of commands: > 1. Place cursor on the letter b. > 2. In the menu, choose Org > Refresh/Reload > Refresh setup current > buffer. Note that you are leaving, on purpose, point in an invisible part of the document. > (I do not know how to access this command directly). > 3. Press TAB on your keyboard. > > If I do this in org-mode 8.3.6, my buffer looks as follows: > > * a > ** b > ... > > In this minimalistic example, pressing TAB once more will bring back the > line with the c, but in more complex examples, some parts of the buffer > seem to "get lost". Moreover, I often find my files garbled like this > when I open them from the agenda. You can reveal text around point with C-c C-r (or even C-u C-c C-r). See `org-reveal' for details. By the way, Org 9.0 (yet to be released) contains a variable to control this: `org-show-context-detail'. You may want to update Org. > If I apply the above sequence of commands using my built-in org-mode > 7.9.3, everything is fine. I can reproduce the same with Org 7.9.3. Regards, -- Nicolas Goaziou
[O] Basic visibility cycling bug in 8.3.6
I am running org-mode 8.3.6 (8.3.6-6-g194e51-elpa @ .../.emacs.d/elpa/org-20161003/) in GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.10.7). In this version, visibility cycling does not work as expected. Consider the following three-line example file: * a ** b ** c Consider the following sequence of commands: 1. Place cursor on the letter b. 2. In the menu, choose Org > Refresh/Reload > Refresh setup current buffer. (I do not know how to access this command directly). 3. Press TAB on your keyboard. If I do this in org-mode 8.3.6, my buffer looks as follows: * a ** b ... In this minimalistic example, pressing TAB once more will bring back the line with the c, but in more complex examples, some parts of the buffer seem to "get lost". Moreover, I often find my files garbled like this when I open them from the agenda. If I apply the above sequence of commands using my built-in org-mode 7.9.3, everything is fine.
