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/)]

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]

--text follows this line--

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

     http://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org-mode mailing list.
------------------------------------------------------------------------

Dear org developers,

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
* second heading
* 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 `integrate' org-cycle reveals an error: `byte-code:
Invalid search bound (wrong side of point)'.  This is a bug.




With point on the first star and and
org-cycle-include-plain-lists set `t' org-cycle reveals:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* 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
* second heading
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


Now move point to `1' and do org-cycle again:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
1) master list...
2) another master list
* second heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
this is ok.


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
      - third sub list item
      - fourth sub list item
   - fourth plain list item
2) another master list
* second heading
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< 
here I would not expect to see the third and fourth sub list
item, since I do not see the first and second one.


Now do org-cycle again:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
1) master list
                                                                                                
   - first plain list item
   - second plain list item
   - third plain list item...
   ****************** TODO inline task
      - third sub list item
      - fourth sub list item
   - fourth plain list item
2) another master list
* second heading
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Only now the first and second sub list item are displayed.


I do not understand this logic: Bug orr feature?


Emacs  : GNU Emacs 24.3.50.1 (i486-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2012-12-02 on dex, modified by Debian
Package: Org-mode version 7.9.2 (release_7.9.2-646-g664217 @ /home/grfz/src/org-mode/lisp/)


Thanks for org-mode, Gregor

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/)]

[Bastien]

Hi Gregor,

I think you are misusing inline tasks, the stars should start 
at the beginning of the line.

HTH,

-- 
 Bastien

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]

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

mostely my fault, only a minor bug remains (was: Re: Bug: inline tasks behave strange with respect to visibility cycling within plain lists)

[Gregor Zattler]

Hi Bastien, org developers,
* Gregor Zattler <telegraph@gmx.net> [25. Dec. 2012]:
> I did the whole thing again but with more care:

Now I learned that although org-inlinetask.el is not in contrib
(anymore), it has to be activated as a module.  

> 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 problem vanished when customizing org-modules to contain
org-inline-task.

However there is a minor bug with respect to folding:

This file:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* 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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

when partially folded looks like this:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
  1) master list
     - first plain list item
     - second plain list item
     - third plain list item...
     - fourth plain list item
  2) another master list
     - two one
     - two two
* second heading...
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

now with the cursor at the "first plain list item", org-cycle
produces:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
* first heading
  1) master list
     - first plain list item
     - second plain list item
     - third plain list item...
********************* TODO inline task...
     - fourth plain list item
  2) another master list
     - two one
     - two two
* second heading...
* third heading
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

somehow visibility-cycling of the first plain list item reveals
the inline task in the third plain list item, while I would
expect that nothing would happen since the first plain list
item does not contain any sub items.


> 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)'.
[...]
> 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.

I couldn't reproduce this bug.  

Sorry for the noise and thanks for org-mode, Gregor

Version infos etc:

This is with recent emacs-snapshot:
GNU Emacs 24.3.50.1 (i486-pc-linux-gnu, GTK+ Version 3.4.2) of 2012-12-24 on dex, modified by Debian

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

I did the test with:

Emacs-snapshot -Q -nw -l ~/.emacs.d/_minimal.org-init.el

with ~/.emacs.d/_minimal.org-init.el being:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
(add-to-list 'load-path "~/src/org-mode/lisp")
(setq org-modules (quote (org-bbdb org-bibtex org-docview org-gnus org-info org-jsinfo org-inlinetask org-irc org-mew org-mhe org-rmail org-vm org-wl org-w3m)))
(org-reload)
(find-file "/tmp/testinlinetask.org")
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<


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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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/)]

[Bastien]

Hi Gregor,

thanks for the detailed report.

Gregor Zattler <telegraph@gmx.net> writes:

> 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.

It might disappoint you, but by take on this is very simple: you
should not try to use inline tasks within plain lists.

I added this note in the comment header of org-inlinetask.el:

  ;; Note that you should not try to use inline tasks within plain list,
  ;; visibility cycling is known to be problematic when doing so.

If anyone is willing to support inline tasks within plain list,
please send a patch.  

Thanks,

-- 
 Bastien