Hi Bastien, org developers, * Gregor Zattler <telegr...@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 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<