[kramdown-users] kramdown table-making has gone completely insane

Thomas Leitner t_leitner at gmx.at
Tue Oct 12 09:21:11 EDT 2010


On 2010-10-12 19:48 +1100 Shawn Van Ittersum wrote:
> Thomas, please know that I have tremendous respect for the very
> powerful software you created.  However, your explanation of this
> particular issue is bordering on ridiculous.  Any human reading that
> example would interpret `||` as a code span, not as a table-cell
> delimiter.  Regardless of the underlying implementation details,
> kramdown's faulty interpretation of this code is a bug or design
> flaw, not a feature.  `||` is a code span, and kramdown's failure to
> recognize it as such doesn't change that fact.

Yes, you are right. Any human would probably see that but what about
these examples:

    This is a *cell | with some | data* here and here*

or

    Of course, you`re good | You are not so good | You`re bad!!!

Can you definitely say that these are *not* table lines?

> As for your prior claim, "kramdown does neither process the contents
> of code spans nor the contents of code blocks," this is clearly not
> true, since you are applying the table interpreter before the block
> interpreter and thus processing the contents of code blocks.  Please
> revisit the implementation design so kramdown can reliably satisfy
> the claim not to process code spans.

You need to know that the table parser *is* a block parser. There has
to be a certain ordering so that parsing block level elements works
correctly. Here is the ordering for the block level parsers:

    :blank_line, :codeblock, :codeblock_fenced, :blockquote, :table,
    :atx_header, :setext_header, :horizontal_rule, :list,
    :definition_list, :link_definition, :block_html,
    :footnote_definition, :abbrev_definition, :block_extensions,
    :block_math, :eob_marker, :paragraph

As you can see, the parser for code blocks is tried before the parser
for tables! So there is no issue here.

If you look at the implementation of the code span parser and the HTML
converter method for code span (or that of the code block
parser/converter), you will see that kramdown does no processing! So my
claim is correct.

In fact, the problem exists only because of how the table parser
currently works (and, naturally, because the code span parser does
*not* process the contents of code spans). As I said before I'm
working on correcting the problem!

-- Thomas


More information about the kramdown-users mailing list