Closed mn4367 closed 9 years ago
The default rule in Markdown is that 0-3 leading spaces is the same as no leading space. 4-7 is the same as 1 tab. And so on.
The proper way to think about spaces is as a mod(4) phenomenon.
EDIT: To clarify, the current behavior is correct. You can indent by one tab/4 spaces to allow backticks inside a code block.
Additionally, you can use mismatched numbers of backticks to prevent pairing.
Thanks, I know about this rule. The problem was, that the new behaviour broke on of my documents because it created an empty code
element which again caused a problem in my XSLT (which is of course not MMDs problem). And that wasn't the case with 4.5.2.
With MMD 4.5.2 the following was possible: (I include all the samples as images because I wasn't able to write down the code in the Github editor)
The result looked like this: This was very fine; I thought that the opening and closing backtick sequences always had to start at the beginning of a line (rule 1) and everything in between those lines is considered to be code. The inner block had to be indented with at least one space to make this work, of course, which is OK.
Indenting the whole fenced block by just one... ... leads to this result ... ... which I think is somehow acceptable because rule 1 wasn't followed.
Processing the very first example with MMD 4.6 leads to this result:
This seems to be either a regression problem or the (presumed) rule 1 is no longer valid (or never existed?). This can only be cured to some extent by indenting the inner backticks by at least 4 spaces... ... but that's rather not what I wanted to achieve.
I have to say that I'd prefer the old behaviour since the rule for using fenced code blocks can be defined clearly (needs to start at the beginning of the line) and it enables a usage like in the first example.
Let me put the question the other way around: if this was changed by intention, what is the advantage of the new behaviour? Have I overlooked something?