BUG Visibility Cycling with inline tasks
Hi, I resend my report with now hopefully all information to reproduce it quickly. Inline tasks are a great feature of org-mode, very useful to include tasks in all sorts of documents without interfering with the document structure. 0. emacs -Q 1. Insert the below snippet into scratch buffer. >>> * Example ** heading 1 x ** heading 2 *** TODO Test access with provided credentials x *** END ** heading 3 *** TODO State "high value" targets x *** END ** heading 4 x (org-mode) (require 'org-inlinetask) <<< 2. Execute each of the 2 elisp statements at the bottom (C-x C-e) 3. Cycle Example to show children 4. Cycle heading 2 This should show the issue: Parts of heading 3 are expanded too. This is also true for the next to cycling steps. Then comes a correct full cycle and the issue repeats. This garbage shown from the next heading(s) can become huge in more complex structures. Org mode version 9.4.6 (9.4.6-gcf30f7 Please confirm the issue. Regards, Michael
Re: BUG Visibility Cycling with inline tasks
Hi Ihor, Thanks for checking. I could narrow down on the issue. It happens after (require 'org-inlinetask) is executed. So to reproduce: 1. emacs -Q 2. paste the following snipped (right into the scratch buffer) 3. execute the two commands at the end C-x C-e for each 4. collapse all (TAB TAB) 5. expand Example (TAB) 5. go to heading 2 and expand it (TAB) This should surface the issue. >>> * Example ** heading 1 x ** heading 2 *** TODO Test access with provided credentials x *** END ** heading 3 *** TODO State "high value" targets :@CB: x *** END ** heading 4 x (org-mode) (require 'org-inlinetask) <<< Am Mo., 20. Sept. 2021 um 10:21 Uhr schrieb Ihor Radchenko < yanta...@gmail.com>: > Michael Dauer writes: > > > What I get after the first org-cycle is: > > * Example > > ** heading 1 > > ** heading 2 > > * ** TODO Test access with provided credentials > > ** heading 3 > > x > > * ** END > > ** heading 4 > > x > > > > I cannot reproduce on latest master and with Org 9.4.4. What I am seeing > is: > > * Example > ** heading 1... > ** heading 2 > * ** TODO Test access with provided credentials... > * ** END > * heading 3... > * heading 4 > > Another cycle reveals the inlinetask contents: > > * Example > ** heading 1... > ** heading 2 > * ** TODO Test access with provided credentials > x > * ** END > * heading 3... > * heading 4 > > Maybe something with your config? Can you reproduce starting from emacs -Q? > > Best, > Ihor >
Re: BUG Visibility Cycling with inline tasks
Michael Dauer writes: > What I get after the first org-cycle is: > * Example > ** heading 1 > ** heading 2 > * ** TODO Test access with provided credentials > ** heading 3 > x > * ** END > ** heading 4 > x > I cannot reproduce on latest master and with Org 9.4.4. What I am seeing is: * Example ** heading 1... ** heading 2 * ** TODO Test access with provided credentials... * ** END * heading 3... * heading 4 Another cycle reveals the inlinetask contents: * Example ** heading 1... ** heading 2 * ** TODO Test access with provided credentials x * ** END * heading 3... * heading 4 Maybe something with your config? Can you reproduce starting from emacs -Q? Best, Ihor
Re: BUG Visibility Cycling with inline tasks
What I get after the first org-cycle is: * Example ** heading 1 ** heading 2 * ** TODO Test access with provided credentials ** heading 3 x * ** END ** heading 4 x So it also shows part of the following heading. This "garbage" can be max more if the following subtree is more complex. it stays after the 2nd and 3rd cycle. Cycles 4 to 6 are OK, then the problem comes again. Am Mo., 20. Sept. 2021 um 07:01 Uhr schrieb Ihor Radchenko < yanta...@gmail.com>: > Michael Dauer writes: > > > Stating collapsed, pressing TAB on the heading 2 already shows the issue. > > Could you describe what is the issue you observe and how it differs from > your expectations? I do not see any problem with visibility on my side. > > Best, > Ihor >
Re: BUG Visibility Cycling with inline tasks
Michael Dauer writes: > Stating collapsed, pressing TAB on the heading 2 already shows the issue. Could you describe what is the issue you observe and how it differs from your expectations? I do not see any problem with visibility on my side. Best, Ihor
Re: BUG Visibility Cycling with inline tasks
Sorry, I forgot: Org mode version 9.4.6 (9.4.6-gcf30f7 Am Sa., 18. Sept. 2021 um 10:27 Uhr schrieb Michael Dauer < mick.da...@gmail.com>: > Hi, > > Inline tasks are a great feature of org-mode, very useful to include tasks > in all sorts of documents without interfering with the document structure. > > But it seems that there are multiple issues with multiple org commands and > inline tasks (visibility, navigation, selection). > > For that reason I already suggested a while ago that the * END line would > be indented 1 level more then the * start of the inline task. By that it > would behave like a normal subtree for all org-commands. > > Here a minimal example of an issue with visibility cycling: > >>> > * Example > ** heading 1 > x > ** heading 2 > *** TODO Test access with provided credentials > x > *** END > ** heading 3 > *** TODO State "high value" targets > :@CB: > x > *** END > ** heading 4 > x > <<< > > Stating collapsed, pressing TAB on the heading 2 already shows the issue. > > IMO the suggested simple (but breaking (but easy to fix)) design change > would make inline tasks more compatible and stable, and even more intuitive > in the expanded visualization. > > Regards, > Michael >
BUG Visibility Cycling with inline tasks
Hi, Inline tasks are a great feature of org-mode, very useful to include tasks in all sorts of documents without interfering with the document structure. But it seems that there are multiple issues with multiple org commands and inline tasks (visibility, navigation, selection). For that reason I already suggested a while ago that the * END line would be indented 1 level more then the * start of the inline task. By that it would behave like a normal subtree for all org-commands. Here a minimal example of an issue with visibility cycling: >>> * Example ** heading 1 x ** heading 2 *** TODO Test access with provided credentials x *** END ** heading 3 *** TODO State "high value" targets :@CB: x *** END ** heading 4 x <<< Stating collapsed, pressing TAB on the heading 2 already shows the issue. IMO the suggested simple (but breaking (but easy to fix)) design change would make inline tasks more compatible and stable, and even more intuitive in the expanded visualization. Regards, Michael
