From: abq@bitrot.link
To: emacs-orgmode@gnu.org
Subject: Re: section continuation
Date: Tue, 27 Dec 2022 20:22:00 +0000 [thread overview]
Message-ID: <248c92c57142c9119ce0b6f51b41da46@bitrot.link> (raw)
In-Reply-To: <9ceaa25e9e84c9c2db5cb385c51eb1db@bitrot.link>
tomas wrote:
> To me, it would be less intuitive (the material under this
> pseudo heading is intended to be level 1, not 2). So you might
> like to add this to the costs. Or not, if that doesn't make
> sense to you :)
As previously written, yes, it can produce the wrong impression. But
swap the lone-dash line and the blank line, and it produces the
impression of a subsection terminator:
* General animals
Some text about general animals
** arthropods
spiders and things
** -
More about animals in general
which has no impact on the proposed meaning or on how the software
should handle it. Likewise no problem with terminating subsections that
contain sub-subsections:
* General animals
Some text about general animals
** arthropods
spiders and things
*** venomous
funnel web spider
** -
More about animals in general
< You had one more compelling downside of
< dash (for dot: perhaps it looks too much like the ellipsis of a folded
< subsection). I actually liked the comma, which has already a job as
< an escape-character for line constructs in Org.
Comma is good for suggesting continuation, if used the way you currently
use dash. But if used the way I propose, and in particular considering
the formatting above, does comma still seem best? If the better
suggestion is termination (because the number of asterisks matches the
section being terminated, not the section being continued), then period
would be more effective.
As for dot's conflict with ellipsis for folded subsections, the solution
to that problem is to not use ellipsis. Better would be like graphical
tree view systems do: a plus or minus sign inside a box icon to the left
of the headline (in the gutter when not using org-indent-mode). This
avoids the misleading dots that appear to be part of the text, and in
org-indent-mode it avoids the misleading single asterisk. (In
org-indent-mode, better to omit the asterisks entirely, and display just
a plus/minus in a box icon.) Fortunately, this has no impact on Org's
file format, except for the traditional ellipsis causing bias against
choosing dot for the subsection termination character.
Anyway... more important is how org-mode interprets it.
First, tell everybody: If you want to avoid all this nonsense, then just
don't ever use a lone-dash (or whatever it'll be) headline.
Second, did I cover all the necessary changes to make
section-continuation generally useful? I.e.
Skip folding of lone-dash sections when folding all the sections at
their level.
Unfold them when unfolding the containing section.
Skip them when jumping to next/previous section.
Skip numbering them.
Display them at one level shallower than currently standard in
org-indent-mode.
This differs from inline tasks, because the latter don't terminate the
preceding section.
And can anybody think of any costs besides the ones already mentioned?
Any adverse interaction with other features?
next prev parent reply other threads:[~2022-12-27 20:23 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-27 13:08 section continuation (was: Is the cascading logic of outlines a feature, or a design bug?) abq
2022-12-27 13:57 ` tomas
2022-12-28 2:22 ` Samuel Wales
2022-12-27 14:15 ` section continuation abq
2022-12-27 15:36 ` tomas
2022-12-27 20:22 ` abq [this message]
2022-12-28 5:17 ` Ihor Radchenko
2022-12-28 8:58 ` tomas
2022-12-29 6:01 ` Tim Cross
2022-12-29 8:57 ` tomas
2022-12-29 9:21 ` Heinz Tuechler
2022-12-29 10:09 ` Jean Louis
2022-12-29 10:42 ` Ihor Radchenko
2022-12-29 14:00 ` Jean Louis
2022-12-31 12:16 ` Ihor Radchenko
2022-12-31 12:26 ` tomas
2023-01-01 21:29 ` Tom Gillespie
2022-12-29 10:28 ` tomas
2022-12-31 12:03 ` Greg Minshall
2022-12-29 10:06 ` Jean Louis
2022-12-29 12:47 ` Max Nikulin
2022-12-28 17:37 ` Timothy
2022-12-28 19:34 ` tomas
2022-12-29 10:21 ` Ihor Radchenko
2022-12-29 10:30 ` tomas
2023-01-01 21:19 ` Marcin Borkowski
2022-12-28 20:01 ` Heinz Tuechler
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=248c92c57142c9119ce0b6f51b41da46@bitrot.link \
--to=abq@bitrot.link \
--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).