Preserve tabs in code blocks (as they are semantic)

Spec
1

Makefiles and some other programming languages give semantic meaning to tabs which is destroyed when the tabs are converted to spaces → the code will no longer work.

Therefore the fact that this is a bug in the spec is not part of the discussion, but already a proven fact.

This is about discussing how to fix the spec’s wording so that the bug is fixed without complicating or altering behavior otherwise. John Gruber’s original spec says:

One level of indentation — 4 spaces or 1 tab — is removed from each line of the [indented] code block.

Which is pretty clear in my eyes. I inserted the [indented] since that version doesn’t know fenced code blocks. This does not say that anything inside a codeblock is to be touched, which includes tabs.

The important part: Only the tabs that are Markdown syntax, i.e. used to determine to which list level or code block a line belongs to is treated the same as four spaces. Tabs inside of code blocks are part of the code, just like any other character, and to be left alone.

So how to convey this in a less convoluted way than I just did (I’m not a native English speaker, sorry)?

2

I think this is a good suggestion. Thanks for pointing out that the change would actually be consistent with the letter of Gruber’s original syntax description. I hadn’t noticed that before. Markdown.pl and virtually all other implementations just globally replace tabs with spaces before processing the document. (The most prominent exceptions are maruku, kramdown, and pandoc with --preserve-tabs). But I agree that it’s a real problem if you can’t put tabs in code blocks.

I’ll have to look at the reference implementations to see how hard it would be to implement this change. Meanwhile, other comments welcome.

3

The simplest way is to use the fenced code blocks to allow this specific corner case.

Anything else is bound to be a pain to use since whitespace is white.

4

I now have some working code and a slightly reworked spec at
https://github.com/jgm/cmark/tree/no-detab
Still not certain about the proposed change, but it seems right to me.
There are undoubtedly more wording changes needed in the spec.