BUG Visibility Cycling with inline tasks

BUG Visibility Cycling with inline tasks

[Michael Dauer]

[-- Attachment #1: Type: text/plain, Size: 1067 bytes --]

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
xxxxx
** heading 2
*************** TODO Test access with provided credentials
xxxxx
*************** END
** heading 3
*************** TODO State "high value" targets
:@CB:
xxxxx
*************** END
** heading 4
xxxxx
<<<

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

[-- Attachment #2: Type: text/html, Size: 1402 bytes --]

Re: BUG Visibility Cycling with inline tasks

[Michael Dauer]

[-- Attachment #1: Type: text/plain, Size: 1278 bytes --]

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.dauer@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
> xxxxx
> ** heading 2
> *************** TODO Test access with provided credentials
> xxxxx
> *************** END
> ** heading 3
> *************** TODO State "high value" targets
> :@CB:
> xxxxx
> *************** END
> ** heading 4
> xxxxx
> <<<
>
> 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
>

[-- Attachment #2: Type: text/html, Size: 1836 bytes --]

Re: BUG Visibility Cycling with inline tasks

[Ihor Radchenko]

Michael Dauer <mick.dauer@gmail.com> 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]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

What I get after the first org-cycle is:
* Example
** heading 1
** heading 2
*              ** TODO Test access with provided credentials
** heading 3
xxxxx
*              ** END
** heading 4
xxxxx

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 <
yantar92@gmail.com>:

> Michael Dauer <mick.dauer@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 1289 bytes --]

Re: BUG Visibility Cycling with inline tasks

[Ihor Radchenko]

Michael Dauer <mick.dauer@gmail.com> writes:

> What I get after the first org-cycle is:
> * Example
> ** heading 1
> ** heading 2
> *              ** TODO Test access with provided credentials
> ** heading 3
> xxxxx
> *              ** END
> ** heading 4
> xxxxx
>

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
xxxxx
*              ** 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]

[-- Attachment #1: Type: text/plain, Size: 1627 bytes --]

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
xxxxx
** heading 2
*************** TODO Test access with provided credentials
xxxxx
*************** END
** heading 3
*************** TODO State "high value" targets
:@CB:
xxxxx
*************** END
** heading 4
xxxxx

(org-mode)
(require 'org-inlinetask)
<<<

Am Mo., 20. Sept. 2021 um 10:21 Uhr schrieb Ihor Radchenko <
yantar92@gmail.com>:

> Michael Dauer <mick.dauer@gmail.com> writes:
>
> > What I get after the first org-cycle is:
> > * Example
> > ** heading 1
> > ** heading 2
> > *              ** TODO Test access with provided credentials
> > ** heading 3
> > xxxxx
> > *              ** END
> > ** heading 4
> > xxxxx
> >
>
> 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
> xxxxx
> *              ** END
> * heading 3...
> * heading 4
>
> Maybe something with your config? Can you reproduce starting from emacs -Q?
>
> Best,
> Ihor
>

[-- Attachment #2: Type: text/html, Size: 2493 bytes --]

BUG Visibility Cycling with inline tasks

[Michael Dauer]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

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
xxxxx
** heading 2
*************** TODO Test access with provided credentials
xxxxx
*************** END
** heading 3
*************** TODO State "high value" targets
xxxxx
*************** END
** heading 4
xxxxx

(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

[-- Attachment #2: Type: text/html, Size: 1574 bytes --]