From: Gregor Zattler <telegraph@gmx.net>
To: emacs-orgmode <emacs-orgmode@gnu.org>
Subject: 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/)]
Date: Tue, 25 Dec 2012 14:26:19 +0100 [thread overview]
Message-ID: <20121225132619.GA29757@boo.workgroup> (raw)
In-Reply-To: <87a9t3sujs.fsf@bzg.ath.cx>
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
next prev parent reply other threads:[~2012-12-25 13:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121225132619.GA29757@boo.workgroup \
--to=telegraph@gmx.net \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).