Do not replace tabs with spaces in code blocks

[ant-222]

md2html replaces with four spaces each tab character used for indentation. Do not do it. CSS has tab-size. The user can preprocess his Markdown if needed.

[ec1oud]

Yeah, that sounds sensible; but then, I like tabs more than most people seem to. I think it's just a matter of handling them smartly in a lot more software.

[ant-222]

@ec1oud

Yeah, that sounds sensible; but then, I like tabs more than most people seem to. I think it's just a matter of handling them smartly in a lot more software.

People's preference for spaces may be due to their (or their editor's) inability to handle tabs. Most of the time, however, it is the former: programmers will routinely align with tabs, so that their neat layouts become all garbled with any tab width except the one intended. This is a grave mistake, for tabs should be used exclusively for intendation, and never for alignment. Once that simple principle is understood, all problems disappear, and code becomes tab-width–agnostic—readable (and editable) with any tab-width setting, letting each prorgrammer use his or her prefferred tab width while retaining the capability for horisontal alignment.

The only (slightly) problematic case is when the initial whitespace is composed of tabs and spaces, which is a rather rare situation, and then the editor should take care to preserve the indent sturcture, instead of re-composing it to minimise character count. Vim has copyindent for that, but I maintain that this should be the default autoindent behavior in all editors, as the easiest to implement, least astonishing, and least destructive.

[mity]

Hmmm. I understand the demand, but note this likely won't be implemented anytime soon, if at all.

I see it as very difficult to implement this correctly. Consider there can be tabs on the boundary of indentation of the block itself and indentation of its contents, with all the crazy potential space/tab combinations, e.g. when the fenced or indented code block is nested within a list item.

I'm not even sure what then should be expected behavior for some odd inputs one can come with.

[ant-222]

@mity

I see it as very difficult to implement this correctly. Consider there can be tabs on the boundary of indentation of the block itself and indentation of its contents, with all the crazy potential space/tab combinations, e.g. when the fenced or indented code block is nested within a list item.

A very good remark, that, but let me first observe that my proposal concerns the HTML–rendering stage, rather than the Markdown–parsing stage. Once the Markdown has been parsed and the AST built, all I ask is to preserve the code block verbatim while rendering the result into HTML.

Now, to your remark. In my case, I just insert my tab–indented code as a fenced code block, which means there is no ambiguity as the indentation of the fences defines where the structural indent ends and the literal code starts. And even in the more complicated cases of nested indentaion, there is no ambiguity for aught I know, quoth the standard:

Tabs in lines are not expanded to spaces. However, in contexts where spaces help to define block structure, tabs behave as if they were replaced by spaces with a tab stop of 4 characters. Thus, for example, a tab can be used instead of four spaces in an indented code block. (Note, however, that internal tabs are passed through as literal tabs, not expanded to spaces.)

I believe any ambiguity is avoided by (among other things) allowing the structural indent to change only one level up or down, so that, is there suddenly appear a text indended with three tab characters, the first indent is considered as introduding a code block, and the rest—as belonging to the code itself, as in this example, where the tabulation has been transparently preserved!