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

Shawn Van Ittersum svicalifornia at gmail.com
Mon Oct 11 07:06:20 EDT 2010

On Mon, 11 Oct 2010 09:50:00 +0200, Thomas Leitner wrote:
> On 2010-10-11 03:03 +1100 Shawn Van Ittersum wrote:
>> More generally, I think that kramdown should ignore the contents of
>> any code block or span.  I can't think of a good reason for kramdown
>> to interpret the contents of code blocks.  If it didn't, then this
>> table creation problem would go away.
> kramdown does ignore the contents of code spans and code blocks.
> However, the parsing code for tables would be much more complex and
> slower if we were to check for pipes in code spans. For example, what
> about this:
>     cell 1 | cell 2 with a `code | span
>     ending here` | cell 4

First, I think that this example should yield:

<td>cell 1</td>
<td>cell 2 with a <code>code | span
ending here</code></td>
<td>cell 4</td>

This can be accomplished fairly easily by first parsing for ` delimiters to find and isolate code blocks.  Once a block is identified as code, then kramdown will not apply to it.

GitHub-flavored Markdown has a clever method of replacing certain blocks with hash digests, so that the block contents cannot be interpreted by Markdown.  For example:

    def gfm_extraction(text)
      md5 = Digest::MD5.hexdigest(text)
      @extractions[md5] = text

    # convert code blocks to hashed extractions
    html.gsub!(%r{\`(.*)?\`}m) { gfm_extraction("<code>#{$1}</code>") ) }

After applying Markdown processing, the hashed blocked are expanded again:

    # Insert extractions
    html.gsub!(/\{gfm-extraction-([0-9a-f]{32})\}/) { @extractions[$1] }

This is very fast.


More information about the kramdown-users mailing list