Re: [asciidoc-lang-dev] Markup for nested blocks

[Sylvain Leroux <sylvain@xxxxxxxxxxx>]

On 09/03/2021 12:54, Dan Allen wrote:> Lex wrote:
>> Agree with everything you say, except that it is not possible to do
>> nesting without varying length or other indication of grouping
>
> I was merely pointing out that a parser *could* be written that matches
> pairs without relying on the varying line length (using a recursive
> descent). But even if it could be done, it shouldn't be done for the
> other reason I stated.

I'm struggling with an edge case right now. According to the docs
(https://docs.asciidoctor.org/asciidoc/latest/blocks/#block-commonalities,
emphasis mine):
____
All blocks can accomodate zero or more lines of metadata stacked
directly *on top of the block*.
____


So, when a parser encounters some metadata before a delimiter, it should
(must?) assume this is the start of a new block. But consider the
following example:

====
a
[example]
====
b
====
c
====

Here `[example]\n====` could be seen as a an _opening_ delimiter.
However, because all delimiters have the same length, the current
implementation of asciidoctor consider it as a _closing_ delimiter
instead and the document is rendered as:

<informalexample>
  <simpara>a</simpara>
</informalexample>
<simpara>b</simpara>
<informalexample>
  <simpara>c</simpara>
</informalexample>



How could we disambiguate this situation in the specs?

* If we say nested blocks MUST have delimiters of different lengths, the
string `[example]` should be part of the first block's content. However,
as of today, it does not appear in the output document.
* If we say metadata unambiguously marks the start of a block, we should
render the above example using nested blocks, despite all the delimiters
having the same length.
* Or we could say: "content that could be understood as metadata is
forbidden before a block closing delimiter" :/



Ideas? Comments?


Regard,
- Sylvain Leroux

Attachment: signature.asc
Description: OpenPGP digital signature