section continuation (was: Is the cascading logic of outlines a feature, or a design bug?)

section continuation (was: Is the cascading logic of outlines a feature, or a design bug?)

[abq]

tomas wrote:
> I already proposed
> having one canonical heading meaning "back to that level", say dash
> or dot

> Now for that to be useful, you'd have to gather enough users who
> like the idea and use the convention. It's a communication medium,
> after all :-)

The question isn't only how people interpret their files, but also how 
their software interprets their files.

Is anyone here aware of anyone who uses a lone dash or dot or comma 
heading for some other purpose? IOW, if future Org versions were to 
treat it as having some special meaning, would it break backward 
compatibility in practice?

So if you fold/select/delete/move/promote/demote/etc a section, it 
processes not only all the subsections, but also all the following 
lone-dash sections at the section's level. If you number sections, 
lone-dash sections don't get numbers.

If you prefer the standard outliner behavior, then just never use 
lone-dash sections.

To bikeshed the character, dash is commonly used in tree viewers to 
indicate a folded heading (with plus sign for unfolded), so maybe a 
different one is better for section continuation. For continuation, 
comma would be more suggestive than period.

Re: section continuation (was: Is the cascading logic of outlines a feature, or a design bug?)

[tomas]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

On Tue, Dec 27, 2022 at 01:08:41PM +0000, abq@bitrot.link wrote:
> tomas wrote:
> > I already proposed
> > having one canonical heading meaning "back to that level", say dash
> > or dot
> 
> > Now for that to be useful, you'd have to gather enough users who
> > like the idea and use the convention. It's a communication medium,
> > after all :-)
> 
> The question isn't only how people interpret their files, but also how their
> software interprets their files.

The second would follow from the first, I guess.

> Is anyone here aware of anyone who uses a lone dash or dot or comma heading
> for some other purpose? [...]

> To bikeshed the character, dash is commonly used in tree viewers to indicate
> a folded heading [...]

Great! I see you're already in the middle of it :-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: section continuation

[abq]

Another idea:

Your example was:

   * General animals
     Some text about general animals

   ** arthropods
      spiders and things

   * -
     More about animals in general

   ** vertebrates
      so-and-so


But to express your intended meaning, how about this instead:

   * General animals
     Some text about general animals

   ** arthropods
      spiders and things

   ** -
     More about animals in general

   ** vertebrates
      so-and-so


Note the extra asterisk before the dash.

The benefits:
Even current org-mode software handles 
fold/select/delete/move/promote/demote/etc, including continuations 
(lone-dash sections), as intended.
No interference with section numbering at the level of the continued 
section.

The costs:
For current software, this interferes with section numbering at the 
subsection level, since continuations count as subsections.
Commands to jump to next/previous section will include continuations.
Folding subsections will fold continuations.

IMO, the benefits outweigh the costs, because the benefits prevent 
problems with editing when using current software, and the costs only 
cause problems with viewing and navigation.

Future versions of Org could:
Skip numbering of lone-dash sections.
Skip folding them when folding subsections.
Skip them when jumping to next/previous section.
Display them at one level shallower than currently standard in 
org-indent-mode, and maybe omit display of the lone-dash line itself.


BTW, this would be another reason to use a character other than dash, 
because you already use dash for an incompatible meaning.

Re: section continuation

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1935 bytes --]

On Tue, Dec 27, 2022 at 02:15:26PM +0000, abq@bitrot.link wrote:
> Another idea:
> 
> Your example was:
> 
>   * General animals
>     Some text about general animals
> 
>   ** arthropods
>      spiders and things
> 
>   * -
>     More about animals in general
> 
>   ** vertebrates
>      so-and-so
> 
> 
> But to express your intended meaning, how about this instead:
> 
>   * General animals
>     Some text about general animals
> 
>   ** arthropods
>      spiders and things
> 
>   ** -
>     More about animals in general
> 
>   ** vertebrates
>      so-and-so

Hm. 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 :)

> IMO, the benefits outweigh the costs, because the benefits prevent problems
> with editing when using current software, and the costs only cause problems
> with viewing and navigation.
> 
> Future versions of Org could:
> Skip numbering of lone-dash sections.
> Skip folding them when folding subsections.
> Skip them when jumping to next/previous section.
> Display them at one level shallower than currently standard in
> org-indent-mode, and maybe omit display of the lone-dash line itself.
> 
> 
> BTW, this would be another reason to use a character other than dash,
> because you already use dash for an incompatible meaning.

Don't count my use case. It is well localised, and shouldn't interfere
with a choice of character. 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.

But we are already bikeshedding: I'd leave that for when you have
enough users. Two people bikeshedding isn't enough fun :)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: section continuation

[abq]

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?

Re: section continuation (was: Is the cascading logic of outlines a feature, or a design bug?)

[Samuel Wales]

i can't offer an enticing bikeshed, but i often do this, which is
possibly tangential but maybe sparks ideas.

* topic
*** REF this entry goes at top of siblings below topic
*** x [x sort of means "the topic per se"]
this is actually the text that belongs to topic, and it is under x
because i need it as a sibling with other siblings.

another issue is that it is confusing enough even with the org model
when i have child tasks below lots of body text.
*** AKEYWORD i want this entry at bot of topic

idk if this is useful to anybody else, but i find myself using x as a
generic "this is the actual topic but it needs siblings" kind of
thing.  it does have one drawback which is that the agenda shows x
instead of the top heading.

it is merely a quick habit.  i wonder if anybody else does it.  there
is no special org behavior or anythng.


On 12/27/22, tomas@tuxteam.de <tomas@tuxteam.de> wrote:
> On Tue, Dec 27, 2022 at 01:08:41PM +0000, abq@bitrot.link wrote:
>> tomas wrote:
>> > I already proposed
>> > having one canonical heading meaning "back to that level", say dash
>> > or dot
>>
>> > Now for that to be useful, you'd have to gather enough users who
>> > like the idea and use the convention. It's a communication medium,
>> > after all :-)
>>
>> The question isn't only how people interpret their files, but also how
>> their
>> software interprets their files.
>
> The second would follow from the first, I guess.
>
>> Is anyone here aware of anyone who uses a lone dash or dot or comma
>> heading
>> for some other purpose? [...]
>
>> To bikeshed the character, dash is commonly used in tree viewers to
>> indicate
>> a folded heading [...]
>
> Great! I see you're already in the middle of it :-)
>
> Cheers
> --
> t
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: section continuation

[Ihor Radchenko]

abq@bitrot.link writes:

> And can anybody think of any costs besides the ones already mentioned? 
> Any adverse interaction with other features?

Export. If those special "continuations" are not considered sections
structurally, it is unclear how to represent them when exporting to
LaTeX/HTML/etc. The most painful is situation with third-party exporters
that may need to be adapted.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: section continuation

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1634 bytes --]

On Wed, Dec 28, 2022 at 05:17:35AM +0000, Ihor Radchenko wrote:
> abq@bitrot.link writes:
> 
> > And can anybody think of any costs besides the ones already mentioned? 
> > Any adverse interaction with other features?
> 
> Export. If those special "continuations" are not considered sections
> structurally, it is unclear how to represent them when exporting to
> LaTeX/HTML/etc. The most painful is situation with third-party exporters
> that may need to be adapted.

That's why I was suggesting a "low profile" approach. "Official" Org
shouldn't have to care about it (after all, for those interested, it
isn't that difficult to make a derived exporter). Perhaps that "feature"
ends up as something needing special exporters (after all, for
(La)TeX, Markdown, (possibly?) OpenDocument, the exporters will have
to do "funny stuff", because the target document model doesn't know
what we are talking about.

For this idea to bear any weight, I think first is having interested
users agreeing on some conventions. The tools will come, I wouldn't
start with those (perhaps only as proof of concept, to test and
validate ideas).

It'd be too early now to commit Org to that, potentially ossifying
stuff of which we don't know yet whether it is a good idea at all.

As far as I am concerned, I don't think the feature is important
enough to complexify Org, but (a) I see that there are people who
really want it (and offer myself as sparring partner to bounce ideas
off) and (b) Org is chock full of features I'd rather not have,
but others need badly. Software is like that :-)

Thanks & cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: section continuation

[Timothy]

[-- Attachment #1: Type: text/plain, Size: 919 bytes --]

Hi all,

2¢ from me: I have yet to see an example which seems like it actually needs the
ability to go “up” a level. Sometimes I need to rethink my initial impulses, but
often it forces me to use a better structure.

Considering the example used in the thread, I would think it lends itself to
something like this:

┌────
│ * General animals
│   Some text about general animals
│ 
│ ** Categories
│ 
│ *** arthropods
│    spiders and things
│ 
│ *** vertebrates
│    so-and-so
│ 
│ *** other animals
│    etc.
│ 
│ ** Overall comments
│   More about animals in general
└────

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.

Re: section continuation

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

On Thu, Dec 29, 2022 at 01:37:32AM +0800, Timothy wrote:
> Hi all,
> 
> 2¢ from me: I have yet to see an example which seems like it actually needs the
> ability to go “up” a level. Sometimes I need to rethink my initial impulses, but
> often it forces me to use a better structure.
> 
> Considering the example used in the thread, I would think it lends itself to
> something like this:

Thanks. I /think/ that's not the point: "classical" text documents
seem to do fine without (let me call it) XML-style nesting (aka
"going back", as witnessed by TeX/LaTeX, which after all, come from
"classical" (scientific) text. We had this in the discussion.

There seem to be a few folks around here which are uncomfortable
with this limitation. My intent is rather to understand where this
discomfort comes from and what we can do about it.

I must admit that I was surprised about that limitation at first,
but seeing how papers and books and TeX and LaTeX do helped to
dispel that irritation of mine. That isn't necessarily the case for
everyone, though.

Just once I had (or thought I had) to have this and I shared here
my "hack", which worked perfectly well (after "enhancing" the one
exporter). But I think I was misusing a document description language
as a data description language (people do such things, disgusting,
I know ;-)

Thanks & cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: section continuation

[Heinz Tuechler]

Timothy wrote/hat geschrieben on/am 28.12.2022 18:37:
> Hi all,
>
> 2¢ from me: I have yet to see an example which seems like it actually needs the
> ability to go “up” a level. Sometimes I need to rethink my initial impulses, but
> often it forces me to use a better structure.
>
> Considering the example used in the thread, I would think it lends itself to
> something like this:
>
> ┌────
> │ * General animals
> │   Some text about general animals
> │
> │ ** Categories
> │
> │ *** arthropods
> │    spiders and things
> │
> │ *** vertebrates
> │    so-and-so
> │
> │ *** other animals
> │    etc.
> │
> │ ** Overall comments
> │   More about animals in general
> └────
>
> All the best,
> Timothy
>

Dear Timoty,

taking your example, it seems logically disturbing to me to put "Some
text about general animals" at a different level than "More about
animals in general".
In other words, if "More about animals in general" deserves an "**
Overall comments" section, why should not "Some text about general
animals" be headed by "** Introductory comments"? I don't propose that
solution, but it seems logically more consistent to me. For myself, I
did not find a good solution, but I frequently encounter similar situations.

best regards,
Heinz

Re: section continuation

[Tim Cross]

<tomas@tuxteam.de> writes:

> As far as I am concerned, I don't think the feature is important
> enough to complexify Org, but (a) I see that there are people who
> really want it (and offer myself as sparring partner to bounce ideas
> off) and (b) Org is chock full of features I'd rather not have,
> but others need badly. Software is like that :-)
>

I agree. While I can understand it is a feature some users may want, it
certainly isn't one I'm interested in and I continue to be very
concerned about the feature growth and increase in complexity I see with
org.  I fear we are losing one of the best features of org - simplicity
and easy customization for individual needs. I find the straight-forward
nature of a tree structure much simpler to work with than one which will
be less tree like and more directed graph like. While it is true the
tree structure found in outline mode does impose some restrictions on
the document layouts you can use, I think that loss in generality is
justified by the gain in simplicity and consistency in other processing,
such as data exports. 

Re: section continuation

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1979 bytes --]

On Thu, Dec 29, 2022 at 05:01:33PM +1100, Tim Cross wrote:
> 
> <tomas@tuxteam.de> writes:
> 
> > As far as I am concerned, I don't think the feature is important
> > enough to complexify Org, but (a) I see that there are people who
> > really want it (and offer myself as sparring partner to bounce ideas
> > off) and (b) Org is chock full of features I'd rather not have,
> > but others need badly. Software is like that :-)
> >
> 
> I agree. While I can understand it is a feature some users may want, it
> certainly isn't one I'm interested in and I continue to be very
> concerned about the feature growth and increase in complexity I see with
> org.  I fear we are losing one of the best features of org - simplicity
> and easy customization for individual needs.

Agreed, so far.

> I find the straight-forward
> nature of a tree structure much simpler to work with than one which will
> be less tree like and more directed graph like.

Strongly disagree.

Both are trees (that's why I prefer to talk about "document model".
It's only so that in Org, only the first child of a section node
can be text, the following must be subsections. In "XML" you just
can intermix subsections and text (actually: any kind of subnodes).

Org is "asymmetric" in this respect: blocks can be mixed freely
with text content (aka paragraphs), sections cannot. But trees
they are all.

> While it is true the
> tree structure found in outline mode does impose some restrictions on
> the document layouts you can use, I think that loss in generality is
> justified by the gain in simplicity and consistency in other processing,
> such as data exports. 

I think it is misleading to cast it in terms of "tree" vs "non-tree" and
this may be part of the current confusion's source.

Cheers

[1] "XML" as a shorthand for the unrestricted structure of an XML
    document model. Then you can restrict it with DTDs, RelaxNGs
    or whatever.
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: section continuation

[Heinz Tuechler]

tomas@tuxteam.de wrote/hat geschrieben on/am 29.12.2022 09:57:
> On Thu, Dec 29, 2022 at 05:01:33PM +1100, Tim Cross wrote:
>>
>> <tomas@tuxteam.de> writes:
>>
>>> As far as I am concerned, I don't think the feature is important
>>> enough to complexify Org, but (a) I see that there are people who
>>> really want it (and offer myself as sparring partner to bounce ideas
>>> off) and (b) Org is chock full of features I'd rather not have,
>>> but others need badly. Software is like that :-)
>>>
>>
>> I agree. While I can understand it is a feature some users may want, it
>> certainly isn't one I'm interested in and I continue to be very
>> concerned about the feature growth and increase in complexity I see with
>> org.  I fear we are losing one of the best features of org - simplicity
>> and easy customization for individual needs.
>
> Agreed, so far.
>
>> I find the straight-forward
>> nature of a tree structure much simpler to work with than one which will
>> be less tree like and more directed graph like.
>
> Strongly disagree.
>
> Both are trees (that's why I prefer to talk about "document model".
> It's only so that in Org, only the first child of a section node
> can be text, the following must be subsections. In "XML" you just
> can intermix subsections and text (actually: any kind of subnodes).
>
Agreed. I think that "allow certain nodes to only have one text element
at the very beginning" is an arbitrary choice.
Inconvenient, but logically cleaner would be to allow for text either
only in leaves, or in any place of the nodes.
The latter appears more natural to me, as it would allow for connecting
words between sub sections and closing remarks at the end of a section.
Usually, one would circumvent the problem by inserting a connecting text
at the end of subsections, although this would offend the hierarchy.
best regards, Heinz

Re: section continuation

[Jean Louis]

Maybe you can include it in Org by:

1. Adding special property for the heading

2. To speed up parsing, first check for that property before any parsing, and then decide
   to parse it as option, otherwise proceed as usual.

3. Possibly include option if such property should be looked up or not.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: section continuation

[Jean Louis]

When I write in Asciidoctor markup, a heading may have it property
like this:

[discrete]
== My heading

and that one will not be counted, so I could have any kind of headings
tangled and can decide which one is part of document structure or not.

Similarly for Org, following could be solution

** My heading
   :PROPERTIES:
   :DISCRETE:
   :END:

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: section continuation

[Ihor Radchenko]

<tomas@tuxteam.de> writes:

> There seem to be a few folks around here which are uncomfortable
> with this limitation. My intent is rather to understand where this
> discomfort comes from and what we can do about it.

From my experience, there is a temptation to have a dedicated "closing"
text at the end of subtree. In particular, literal configs are often
structured as

* Heading 1

#+begin_src emacs-lisp
(when condition
#+end_src

** Sub-heading 1
...
** Sub-heading N

** extra

#+begin_src emacs-lisp
) ; closing ")"
#+end_src

* Heading 2

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: section continuation

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

On Thu, Dec 29, 2022 at 10:21:55AM +0100, Heinz Tuechler wrote:

[...]

> Agreed. I think that "allow certain nodes to only have one text element
> at the very beginning" is an arbitrary choice.

There are many arbitrary choices when designing a data structure to
represent text.

> Inconvenient, but logically cleaner would be to allow for text either
> only in leaves,

You'd regret that quickly: what do you do for inline markup (e.g.
bold, italics)? You'd have to introduce a special markup for
"normal" text. Good-bye "lightweight markup" :)

> or in any place of the nodes.

This is XML's "mixed content". Note that specific XMLs can and
do limit that, via DTDs or other validation restrictions (aka
schema). If you're doing text using some suitable XML schema,
you most probably won't be able to put a whole paragraph whithin
a section title. Or a table. If you want a whole italics stretch
straddling a paragraph boundary, you'll have to close it before
the paragraph's end and re-open it next paragraph or something
(although they might, logically or philosophically, belong
together).

Human language is too exciting to fit into a tree structure.

> The latter appears more natural to me, as it would allow for connecting
> words between sub sections and closing remarks at the end of a section.
> Usually, one would circumvent the problem by inserting a connecting text
> at the end of subsections, although this would offend the hierarchy.
> best regards, Heinz

You'll always end up offending some hierarchy some of the time.
In some places you can be sent to jail for that ;-)

No, seriously: Document models sometimes get stretched to data
description languages (I always cringe when people talk about
a JSON or YAML "document") and vice-versa. This is a strength,
but also a weakness.

And don't forget, OASIS's OpenDocument format also doesn't seem
to support "going back". Perhaps for a reason.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: section continuation

[tomas]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Thu, Dec 29, 2022 at 10:21:52AM +0000, Ihor Radchenko wrote:
> <tomas@tuxteam.de> writes:
> 
> > There seem to be a few folks around here which are uncomfortable
> > with this limitation. My intent is rather to understand where this
> > discomfort comes from and what we can do about it.
> 
> >From my experience, there is a temptation to have a dedicated "closing"
> text at the end of subtree. In particular, literal configs are often
> structured as
> 
> * Heading 1
> 
> #+begin_src emacs-lisp
> (when condition
> #+end_src
> 
> ** Sub-heading 1
> ...
> ** Sub-heading N
> 
> ** extra
> 
> #+begin_src emacs-lisp
> ) ; closing ")"
> #+end_src
> 
> * Heading 2

Must be our deformed "computer folks" brains. Too many years of
Djkstra's "goto considered harmful" or something ;-)

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: section continuation

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> When I write in Asciidoctor markup, a heading may have it property
> like this:
>
> [discrete]
> == My heading
>
> and that one will not be counted, so I could have any kind of headings
> tangled and can decide which one is part of document structure or not.

Could you please elaborate what you mean by "not be counted"?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: section continuation

[Max Nikulin]

On 28/12/2022 03:22, abq@bitrot.link wrote:
> 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.

- Various operations with subtrees: kill, yank, refile
- Getting refile/goto targets
and perhaps more functions spread over Org .el files. That is why it is 
hardly viable as a 3rd party extension.

It still would be a tree, but with interleaved block-level text elements 
and subheadings, while currently subheadings must follow heading text. 
What is more close to graph is org-transclusion.

Certainly more liberal structure may confuse readers. It has advantages 
for early drafts and notes more close to mind maps. During collection of 
notes it can not be anticipated which peace of information will be 
expanded with a lot of details. Before publishing document should be 
reworked to make it more linear.

HTML documents may be more interactive and have more decorations than 
printed papers, so I am unsure concerning the export common denominator 
argument. There is a variant of continue parent section for poors: 
create a 1 level deeper subsection "<title> (continued)".

I am still in doubts if increased complexity and performance impact 
outweigh benefits.

Re: section continuation

[Jean Louis]

* Ihor Radchenko <yantar92@posteo.net> [2022-12-29 13:44]:
> Jean Louis <bugs@gnu.support> writes:
> 
> > When I write in Asciidoctor markup, a heading may have it property
> > like this:
> >
> > [discrete]
> > == My heading
> >
> > and that one will not be counted, so I could have any kind of headings
> > tangled and can decide which one is part of document structure or not.
> 
> Could you please elaborate what you mean by "not be counted"?

It is not counted as part of the structure, see PDF below.

https://gnu.support/images/2022/12/2022-12-29/A8D99EA3-9341-4A59-945B-851F68F440E7.pdf

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: section continuation

[Greg Minshall]

possibly a candidate for the .signature file...

> Human language is too exciting to fit into a tree structure.

:)

Re: section continuation

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

>> Could you please elaborate what you mean by "not be counted"?
>
> It is not counted as part of the structure, see PDF below.
>
> https://gnu.support/images/2022/12/2022-12-29/A8D99EA3-9341-4A59-945B-851F68F440E7.pdf

What I see is an equivalent of UNNUMBERED heading property. See
https://orgmode.org/manual/Export-Settings.html

AFAIU, we are talking about much more significant changes to the Org
document schema. It is probably best illustrated using html export.

Consider the following Org example document:

* Heading

Some introductory text

** Sub-heading 1

Cras placerat accumsan nulla.

** Sub-heading 2

Vivamus id enim.

<some kind of markup to signal "Heading" continuation>

Closing text that belongs to "Heading", but not "Sub-heading 2".

---------

HTML:

<div class="outline-1">

<h2><span class="section-number-2">1.</span> Heading</h2>
<p>
Some introductory text
</p>


<div class="outline-3">
<h3><span class="section-number-3">1.1.</span> Sub-heading 1</h3>
<p>
Cras placerat accumsan nulla.
</p>
</div>
<div class="outline-3">
<h3><span class="section-number-3">1.2.</span> Sub-heading 2</h3>
<p>
Vivamus id enim.
</p>
</div>


<p>
Closing text that belongs to "Heading", but not "Sub-heading 2".
</p>
</div>

Note that both introductory text and closing text belong to the same "div".

There is no equivalent in LaTeX/PDF.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: section continuation

[tomas]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

On Sat, Dec 31, 2022 at 12:16:39PM +0000, Ihor Radchenko wrote:
> Jean Louis <bugs@gnu.support> writes:

[...]

> What I see is an equivalent of UNNUMBERED heading property. See
> https://orgmode.org/manual/Export-Settings.html
> 
> AFAIU, we are talking about much more significant changes to the Org
> document schema. It is probably best illustrated using html export.

Exactly

[...]

> Note that both introductory text and closing text belong to the same "div".
> 
> There is no equivalent in LaTeX/PDF.

Nor in any "book-like" medium I know of. Although those sometimes get by
with pretty ambiguous tricks which need the reader's brain's cooperation
(and which are bound to defeat normalisation, let alone tree structure).

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: section continuation

[Marcin Borkowski]

On 2022-12-29, at 11:30, tomas@tuxteam.de wrote:

> On Thu, Dec 29, 2022 at 10:21:52AM +0000, Ihor Radchenko wrote:
>> <tomas@tuxteam.de> writes:
>> 
>> > There seem to be a few folks around here which are uncomfortable
>> > with this limitation. My intent is rather to understand where this
>> > discomfort comes from and what we can do about it.
>> 
>> >From my experience, there is a temptation to have a dedicated "closing"
>> text at the end of subtree. In particular, literal configs are often
>> structured as
>> 
>> * Heading 1
>> 
>> #+begin_src emacs-lisp
>> (when condition
>> #+end_src
>> 
>> ** Sub-heading 1
>> ...
>> ** Sub-heading N
>> 
>> ** extra
>> 
>> #+begin_src emacs-lisp
>> ) ; closing ")"
>> #+end_src
>> 
>> * Heading 2
>
> Must be our deformed "computer folks" brains. Too many years of
> Djkstra's "goto considered harmful" or something ;-)

This.  Also, I guess "normal" people are perfectly fine with attaching
the "closing" to the last subsection or putting it into a dedicated
subsection.

Best,

-- 
Marcin Borkowski
http://mbork.pl

Re: section continuation

[Tom Gillespie]

I haven't seen anyone mention using the :ignore: tag that
is provided by ox-extra in contrib. I know that it doesn't have
the exact semantics of un-nesting a div as seen in html, but
the effect is similar enough.

If you _really_ want to hack something for html, you can
insert a div manually using #+html and it should more or
less work out.

Having worked extensively on org-syntax, I can say that
there is pretty much zero possibility that this can be
shoved in or handled at the syntax level or even at the
structural level beyond something like the :ignore: tag.

A heading is a heading, and we would break countless
user's documents if we suddenly gave headings with a
particular structure special status (I'm also against the
special status that inlinetasks receive and think that
they should not be included in the formal spec but
left as an extension specific to the elisp implementation,
but that is another conversation).