A markdown code fence can be `~~~` about go-testmark HOT 4 CLOSED

it could be a feature such that ~~~ code fences are deliberately ignored by testmark, but either way it should probably called out specifically in the readme.

from go-testmark.

Holy smokes. Yeah, I've never heard of that syntax before. And I did think I've heard of everything.

I... am inclined to call this specificity a feature, yes. I'm going to think on it for a while, but that's kinda my first impression.

The reasoning: it's more important for testmark to be simple than it is for it to support the most outlandish features of markdown. This is important because that it's something we want to be quickly implementable in any language: it should not be a burden to adopt it in new languages. It is also generally good for test fixtures to be as simple as possible, holistically. And ultimately, I struggle to think of ways people would need to put these syntax variations to use, so to invest effort and complexity into them seems like a negative-value move.

I'm also struggling a bit to decide whether I think all of the variations CommonMark describes are... something I'd consider normative. Markdown is always a special beast because it has been very informally specified for most of its life. As a result, "what markdown is" is more of a question of what the predominant majority of community and tools do with it than a single specific formal thing. CommonMark, though it introduces some very well-written and thorough clarifications (which I often appreciate)... also sometimes adds features, and introduces interesting opinions, and sometimes, I'm not sure I consider them all "markdown". Given how incredibly rarely I've seen ~~~ delimiters in the wild, my impulse is to see them as a "that's interesting, CommonMark pat pat" sort of thing.

At any rate, I highly appreciate this information, thank you for bringing it up!

from go-testmark.

Some quick jots about other things I've read from the linked CommonMark document, as well as Gruber's original documents, which surprised me a bit... and also just some opinions that come to mind, as I think about "what is markdown" to me:

• Turns out the entire triple-backtick thing is an invention that's more recent than the "original" markdown? Huh. (I knew the syntax hint thing was a GFM extension, but I didn't know triple-backtick entirely was a non-original invention.)

• But I note that backticks are in the list of things that are expected to need escaping in the original, whereas tildes are not. And backticks have signalled preformatting/"code" since the beginning (just not necessarily as multi-line blocks). So that at least is a vote in favor of the semantic antecedents for backticks meaning "code".

• I associate tildes with strikethrough. Also not in the original markdown, or even half of the modern tools, but nonetheless: I expect tildes to either do nothing, or create a strikethrough. This is not a spec-driven comment, just a "feels" one, but: Tildes doing codeblocks "feels wrong" to me, and I don't think I'd be making the markdown community and ecosystem better by encouraging or supporting their use for this.

• Indent-triggered codeblocks are indeed, um, uufdah. They are in original markdown. But I'm definitely going to ignore them. Their rules are just too strange and too arbitrary. The number 3 is different than the number 4 in the context of indent-triggered codeblocks. Nope.

• CommonMark claims: "Closing fences may be preceded by up to three spaces of indentation, and their indentation need not match that of the opening fence"... you know what, no. Just no. Nope. I don't know who that's for, but no. That is the most unnecessary and arbitrary complexity I've ever seen in my life, and no. I won't have it.

• It is apparently also supposed to be the case in CommonMark that the initial code fence can be indented, and if so, that indentation should be stripped from the content. I... again, cannot imagine who this feature is for, because it also only works with a certain number of spaces before it breaks and does something logically different, and like... why. No, no we're not having this. Testmark is not going to pre-process content that way because it's insane there's no good reason for the complexity, just to get such a limited feature that's so very likely to surprise and confuse someone.

• Ah, hey. See just above, how tilde does strikethrough? Heh.

• It is apparently also supposed to be the case in CommonMark that the code fence can be any number of backticks (or tildes)... and the closing block can be longer, but not shorter. This is a feature that, yet again, I cannot figure out who serves, or why anyone would want this. You can use it to embed another, shorter, character sequence, which would otherwise be a code fence -- which would seem valuable to me, except... that's the most complex form of escaping I've ever heard of. I've never seen someone do this. I've wondered how one would do this before, and yet never seen this be used. I feel like to community adoption rate for this feature is so near to zero as to be dismissable. (Also, why on earth are longer fence terminators allowed? Just to maximize the amount of visual chaos one could put in a document out of sheer persnickety malice? Goodness gracious.)

• Tangent: Oh, the syntax hint in a code block is called an "info string" by the CommonMark spec. I should rename that field in the testmark API to that name (I think I called it "block tag", before knowing a proper name for it). Okay.

Meta analysis: I got increasingly hostile feelings towards many of CommonMark's features regarding code blocks as I read more about them, heh.

Every time there's a divergence between what testmark's first-day parser did, and what CommonMark suggests one should do when parsing codeblocks... the CommonMark suggestion is simultaneously wildly more complex; has very weird edge cases and limitations; and seems utterly useless in every situation I can imagine.

The one feature that seems closest to potentially useful is the ability to use elongated code fences in order to contain other sequences that could've been code fences in the data. However, for that feature to actually be useful, especially in the light of programmatic patching of these documents... one would have to choose how many characters long to make their code fence based on the content. It would be possible to define that, but it seems relatively complicated, and I suspect such a feature would be more likely to surprise and confuse users than to delight them.

summary:

Markdown is definitely an emergent beast.

I think holistically it's going to be a good choice to keep testmark simple, and keep doing what its first-day parser did. Simple is good.

from go-testmark.

I've added some documentation about this to one of the README_*.md files, and so will now close this :)

from go-testmark.