Re: Bug: inline tasks behave strange with respect to visibility cycling within plain lists [7.9.2 (release_7.9.2-646-g664217 @ /home/grfz/src/org-mode/lisp/)]

[Gregor Zattler <telegraph@gmx.net>]

Hi Bastien, org developers,
* Bastien <bzg@altern.org> [24. Dec. 2012]:
> I think you are misusing inline tasks, the stars should start
> at the beginning of the line.

thank you for spending some of your holiday on this.  The blanks
at the beginning of the inline task were an artefact of
selecting/pasting, killing/yanking.  Sorry for this.  I did the
whole thing again but with more care:


This is with recent Emacs-snapshot:
GNU Emacs 24.3.50.1 (i486-pc-linux-gnu, X toolkit, Xaw scroll bars) of 2012-12-24 on dex, modified by Debian

and recent org-mode (via `make up1'):
Org-mode version 7.9.2 (release_7.9.2-881-g99c873 @ /home/grfz/src/org-mode/lisp/)

The test suite says:
"Ran 320 tests, 320 results as expected (2012-12-25 13:07:27+0100)
7 expected failures"

I did the following test with
`emacs-snapshot -Q -nw -l ~/.emacs.d/_minimal.org-init.el /tmp/testinlinetask.org'

with `~/.emacs.d/_minimal.org-init.el' being:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
(add-to-list 'load-path "~/src/org-mode/lisp")
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

and /tmp/testinlinetask.org being:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
  1) master list
     - first plain list item
     - second plain list item
     - third plain list item
        - first sub list item
        - second sub list item
************************* TODO inline task
        - third sub list item
        - fourth sub list item
     - fourth plain list item
  2) another master list
     - two one
     - two two
* second heading
  1) master list two one
     - plain list
     - plain list
  2) masterlist two two
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<




I often want to use inline tasks within plain lists.

The following org file shows a bug and a problem with inline
tasks in plain lists with respect to visibility cycling
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
  1) master list
     - first plain list item
     - second plain list item
     - third plain list item
        - first sub list item
        - second sub list item
************************* TODO inline task
        - third sub list item
        - fourth sub list item
     - fourth plain list item
  2) another master list
     - two one
     - two two
* second heading
  1) master list two one
     - plain list
     - plain list
  2) masterlist two two
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

In Overview it looks like this
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading...
* second heading...
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


With point on the first star and org-cycle-include-plain-lists
set to `As children of outline heading' org-cycle reveals an
error: `byte-code: Invalid search bound (wrong side of point)'.
This is a bug.

The display looks now like this:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
  1) master list...
************************* TODO inline task...
* second heading...
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<




Since this resulted in an error I now begin in overview again,
this time with `org-cycle-include-plain-lists' set to `t':

OVERVIEW:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading...
* second heading...
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

With cursor on first star do org-cycle one time:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
  1) master list
     - first plain list item
     - second plain list item
     - third plain list item
        - first sub list item
        - second sub list item
************************* TODO inline task...
* second heading...
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Here I do not see the second half of the first `master list' nor
the second master list.  This is hinted at with the ellipses after
the inline task but I understand inline task as not "disturbing"
cycling.  Therefore I would expect to see only the children of
the first heading:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
  1) master list
  2) another master list
* second heading
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



Now move point to `1' and do org-cycle again:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
  1) master list...
************************* TODO inline task...
* second heading...
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

In the echo area it org-mode says: "FOLDED": Now the list `1)' is
folded but without the inline task.  I would expect to not see
the inline task.


Now with point still on `1' do org-cycle again:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
  1) master list
     - first plain list item
     - second plain list item
     - third plain list item...
************************* TODO inline task...
* second heading...
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

In the echo area it org-mode says: "CHILDREN": here I would
expect to see the fourth plain list item but it is still hidden
under the inline task.

Now with point still on `1' do org-cycle again:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
  1) master list
     - first plain list item
     - second plain list item
     - third plain list item
        - first sub list item
        - second sub list item
************************* TODO inline task...
* second heading...
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

In the echo area it org-mode says: "SUBTREE": Now I see the first
and second sub list item but but I would expect to also see the
third and fourth sub list item and the fourth plain list.



Summary: 

1) With respect to visibility cycling I would expect to see
   inline tasks as normal text or plainlist item.  I would not
   expect the display of children or subtrees to be cut of
   immediately after an inline task.  

   This is my main concern.  (Hierarchical) plain lists are so
   useful.  Tasks are useful.  One workaround to combine the
   two would be to use headings instead of plain lists.  But this
   looks terrible even with the `hidestars' option and and
   especially in all kinds of exports.

2) I would not expect to see an error when doing org-cycle with
   certain variable settings.  If org-mode is not able to handle
   this situation it should tell so in a way the user is able to
   act upon.



Thanks for org-mode, Gregor