Code fences and backtick strings are not fully disambiguated

[lolbinarycat]

consider the following cases:

1 ```

2 ``` 222 ```

According the dingus, 1 is a code fence that is not part of a fenced code block, and 2 is a code span.

Reading through the spec, it's not clear why this is, or why the following couldn't be interpreted as a code span:

3 ```
333
```

after all, this is a valid code span:

4 ``
444
``

If this is because "block structures take precedence over inline structures", and because code fences are a separate AST element that can exist detached from a code block, then why is 2 not parsed as two code fences? the spec does not say that a line cannot contain 2 code fences.

[vassudanagunta]

``` not at the beginning of a line is not a code fence for the same reason that >, ### and 3. not at the beginning of a line are not a block quote marker, an ATX heading and list marker, respectively.

According the dingus, 1 is a code fence that is not part of a fenced code block

because code fences are a separate AST element that can exist detached from a code block

I tried it in the dingus and do not see what you describe.

3 ```
333
```

Because of block structure precedence, the third line is parsed as the opening of a fenced code block. Thus the backticks on the first line have no corresponding closing backticks, and thus treated as regular text.

[lolbinarycat]

@vassudanagunta ah, I see the error now. I'm not used to grammars that require infinite lookahead.

The following is a code span:

5 ```
555 ```

still, I think these should be added to the spec as examples, as it would be very easy for an implementor to misread how these all should interact.

[vassudanagunta]

grammars that require infinite lookahead.

That's one way to look at it.

Another way is as two separate grammars: the block grammar and the inline grammar. Neither of these two parsers require indefinite lookahead.

The two-pass parsing strategy that is described in the spec's appendix, that is implemented by the reference implementation, and that (i'm pretty sure) all other efficient parsers use, embody this other way of looking at it.