Re: [asciidoc-lang-dev] Whitespace handling

[Lex Trotman <exciidoc@xxxxxxxxx>]

...

> [...] if you recurse on each character of a block
> delimiter then return on each character of the next you should be back
> where you started, otherwise its not a matching delimiter. But
> testing of section and list depth is trickier. Its the way some
> functional languages do looping (and C++ Template Metaprogramming).  But
> that sort of recursion isn't really the sort of thing I would try using
> in a specification, only full Computer Scientists would understand, and
> we want the specification to be clear to writers checking edge cases of
> their documents I would think.
>

I tried something like that a couple of days ago:


block := '=' block '=' | block-content
block-content := EOL block-list
block-list := (text EOL | block EOL ) block-list | ε
                          ^^^^^

As you said, the tricky part is when dealing with nested blocks. I
didn't find a way to handle the constraint "the nested block delimiter's
length must be different from the length of the delimiter for any
enclosing block." For that you need to keep track of all open parent
blocks and that didn't fit well with my approach of the problem. This
issue is somewhat related to the question I asked yesterday
(https://www.eclipse.org/lists/asciidoc-lang-dev/msg00141.html).

The docs https://docs.asciidoctor.org/asciidoc/latest/blocks/nest/ actually specify that nested blocks should grow in length, so its only necessary to compare it to the current enclosing length.  If the current implementation does not enforce that, it still accepts it.

Part of the specification process is to remove the need to reference the behaviour of a "reference implementation" to be compliant.

The specification process needs to decide if it is to be increasing, as documented, and that implementations need to enforce it, or not.

 

At this point, I gave up trying to implement an RD parser for block
parsing. I just tokenize the input and use a stateful object to
construct the tree from the tokens stream. The good thing is, that way,
I get rid of backtracking while parsing at the block level. And after
all, this solution is not that inelegant ;)

I just follow the docs :-)

Of course passing the current length to compare to is another of the uses of my extensions to PEG.

Cheers

Lex

 

- Sylvain


_______________________________________________
asciidoc-lang-dev mailing list
asciidoc-lang-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/asciidoc-lang-dev