I’m slightly confused by the output of example 126 whose input is "```\n" and output:
My reading is is that we have a(n empty) line here and that is should rather be:
Since the spec says:
If the end of the containing block (or document) is reached and no closing code fence has been found, the code block contains all of the lines after the opening code fence until the end of the containing block (or document).
My intuition was that to explicitely simulate the closure of an autoclosing fence block ``` you’d append: \n``` since that’s the only reliable to do it. But that doesn’t seem to be the case, the rule rather seems to be append : \n``` if the last line is non-empty and ``` if the last line is empty.
More precisely both this input (no final newline):
I don’t think this logic can be inferred from the current text – I then thought it was an application document’s initial an trailing blank line stripping, but as shown above it doesn’t seem to apply to autoclosing blocks, which in turn could also be clarified.
First, you’re using the wrong kind of intuition. Markdown and CommonMark aren’t looking at this from a parser’s perspective, but from that of the human eye. Second, it’s wrong to call an unclosed fence block “auto-closing”. The idea here is not to make closing fences optional, but to gracefully handle the situation when a closing fence is missing.
Because these do not look the same to the human eye. You can see a blank line in the second case.
So I guess, given the above, a single blank line is ignored at the end of input ?
Not really it seems, in the reference implementeations a final blank line is not ignored, only a final empty line seem to be. That is "```\n\n " 2 (two final spaces) gives:
Which has two lines and the final one two spaces.
I think this is a flaw, as to the human eye the plain text looks identical to "```\n", and ideally it should be corrected, but I don’t think it’s a priority because it’s a flaw in CommonMark’s attempt to gracefully handle flawed input (missing closing fence). The plain text author should use a closing fence to make explicit their intent with regard to trailing blank lines in the code, or the lack thereof.
Second, it’s wrong to call an unclosed fence block “auto-closing”. The idea here is not to make closing fences optional, but to gracefully handle the situation when a closing fence is missing .
Not sure I see what that distinction brings to the discussion. But in any case all that still doesn’t tell me where in the specification is the logic that defines all this and what the exact rules are. If it’s
a final empty line is ignored
Then I personally can’t infer that from the text.
Regarding the discussion about intuitions personally I’m not here to define the standard but to implement it, so I’m not really interested in it. But if I had to design the standard I would say that being able to remove or add a trailing code fence without changing the concrete content of the document would be a good property for humans as well (especially since code fences are for verbatim text). UX is not only about visuals.
So I guess something need fixing, either the spec or these implementations. The spec says:
Blank lines at the beginning and end of the document are also ignored.
But first that’s ambiguous, is it one line at the beginning and one at the end or multiple lines ? And at least for the cmark reference implementation on code blocks and HTML that’s one empty (vs blank) final line that gets ignored.
The parser simply adds a newline to the end of content that doesn’t end in a newline, before parsing. That is why these cases don’t differ. (It’s a general expectation that text files end with a newline, and to keep things simple we ensure that this expectation is met before parsing.)
Ah I see, my problem seems to be with the definition of line. That is characters and a line ending vs characters and lines incrementing on newlines, like editors do. The file "\n" gives you either one line or two depending on the definition. Sorry used the wrong def.
I guess it makes more sense but I think even equipped with the right definition these examples need clarification (witness the difference between the dingus and cmark).