[kramdown-users] kramdown table-making has gone completely insane
Shawn Van Ittersum
svicalifornia at gmail.com
Tue Oct 12 04:48:01 EDT 2010
On Tue, 12 Oct 2010 09:34:22 +0200, Thomas Leitner wrote:
> On 2010-10-12 05:41 +1100 Shawn Van Ittersum wrote:
>> Sorry for the confusion about code spans and code blocks. But if
>> kramdown does not process the contents of code spans, then how do the
>> pipe characters in Matt's example get interpreted as table cell
>> delimiters? They're inside a code span:
>> require 'kramdown'
>> s = <<END
>> The operator `||` is called logical-or.
>> puts Kramdown::Document.new(s).to_html
> This is easily explained: The kramdown parser has basically two stages.
> The first stage parses the document line by line and builds the tree of
> all *block level elements*. After that the text in the block level
> elements is parsed using the span level parser which returns text and,
> possibly, span level elements.
> So your assumption that the above document line contains a code span is
> only correct *if* the line is parsed as paragraph. However, the table
> parser is invoked before the paragraph parser (because everything that
> is not any valid other kramdown block level element is a paragraph),
> finds the pipes, concludes that it is a table line, splits the line
> into cells using the pipes as separators and boom: no more code span!
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.
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.
More information about the kramdown-users