* 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/)]
@ 2012-12-04 17:32 Gregor Zattler
2012-12-24 8:50 ` Bastien
0 siblings, 1 reply; 5+ messages in thread
From: Gregor Zattler @ 2012-12-04 17:32 UTC (permalink / raw)
To: emacs-orgmode
--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
^ permalink raw reply [flat|nested] 5+ messages in thread* 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/)]
2012-12-04 17:32 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
@ 2012-12-24 8:50 ` Bastien
2012-12-25 13:26 ` Gregor Zattler
0 siblings, 1 reply; 5+ messages in thread
From: Bastien @ 2012-12-24 8:50 UTC (permalink / raw)
To: emacs-orgmode
Hi Gregor,
I think you are misusing inline tasks, the stars should start
at the beginning of the line.
HTH,
--
Bastien
^ permalink raw reply [flat|nested] 5+ messages in thread
* 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/)]
2012-12-24 8:50 ` Bastien
@ 2012-12-25 13:26 ` Gregor Zattler
2012-12-28 12:08 ` 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
2012-12-29 10:06 ` 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
0 siblings, 2 replies; 5+ messages in thread
From: Gregor Zattler @ 2012-12-25 13:26 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 5+ messages in thread* mostely my fault, only a minor bug remains (was: Re: Bug: inline tasks behave strange with respect to visibility cycling within plain lists)
2012-12-25 13:26 ` Gregor Zattler
@ 2012-12-28 12:08 ` Gregor Zattler
2012-12-29 10:06 ` 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
1 sibling, 0 replies; 5+ messages in thread
From: Gregor Zattler @ 2012-12-28 12:08 UTC (permalink / raw)
To: emacs-orgmode
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
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
^ permalink raw reply [flat|nested] 5+ messages in thread* 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/)]
2012-12-25 13:26 ` Gregor Zattler
2012-12-28 12:08 ` 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
@ 2012-12-29 10:06 ` Bastien
1 sibling, 0 replies; 5+ messages in thread
From: Bastien @ 2012-12-29 10:06 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-12-29 10:14 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-04 17:32 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
2012-12-24 8:50 ` Bastien
2012-12-25 13:26 ` Gregor Zattler
2012-12-28 12:08 ` 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
2012-12-29 10:06 ` 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
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).