From matt at tidbits.com  Sun Aug 12 15:33:29 2012
From: matt at tidbits.com (Matt Neuburg)
Date: Sun, 12 Aug 2012 08:33:29 -0700
Subject: [kramdown-users] block parsing not recursive?
Message-ID: <221F5257-ACC9-433F-ADBD-4B976265AD4B@tidbits.com>

I have complete HTML but I want to sweep through it with kramdown so that kramdown can apply smart quotes, turn underlines into <em>, turn [...](...) into <a>, and all that other cool stuff. I can't figure out how to do that. The stuff I try seems to be non-recursive; there are tags it doesn't touch.

(1)

s = <<END
<div markdown="1">
<p>This is a _great_ text</p>
</div>
END

p Kramdown::Document.new(s).to_html
# => "<div>\n  <p>This is a _great_ text</p>\n</div>\n"

Shouldn't markdown="1" work recursively downward, so that _great_ is parsed into <em>?

(2)

Okay, so let's try :parse_block_html instead:

s = <<END
<div markdown>
<p>This is a _great_ text</p>
<table>
<p>This is a _great_ text</p>
</table>
</div>
END

p Kramdown::Document.new(s, :parse_block_html => true).to_html
# => "<div>\n  <p>This is a <em>great</em> text</p>\n  <table>\n<p>This is a _great_ text</p>\n</table>\n</div>\n"

So now we do recurse down into the first <p> tag. But what's up with the <table> tag? It seems to block recursion down.

m.

--
matt neuburg, phd = matt at tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Programming iOS 5! http://shop.oreilly.com/product/0636920023562.do
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.com



From t_leitner at gmx.at  Mon Aug 27 20:15:42 2012
From: t_leitner at gmx.at (Thomas Leitner)
Date: Mon, 27 Aug 2012 22:15:42 +0200
Subject: [kramdown-users] block parsing not recursive?
In-Reply-To: <221F5257-ACC9-433F-ADBD-4B976265AD4B@tidbits.com>
References: <221F5257-ACC9-433F-ADBD-4B976265AD4B@tidbits.com>
Message-ID: <20120827221542.31d8b2ff@noweto>

On 2012-08-12 08:33 -0700 Matt Neuburg wrote:
> Shouldn't markdown="1" work recursively downward, so that _great_ is
> parsed into <em>?

No, the markdown attribute is only applied to the content of the tag
itself, not to other HTML tags found within.

> (2)
> 
> Okay, so let's try :parse_block_html instead:
> 
> s = <<END
> <div markdown>
> <p>This is a _great_ text</p>
> <table>
> <p>This is a _great_ text</p>
> </table>
> </div>
> END
> 
> p Kramdown::Document.new(s, :parse_block_html => true).to_html
> # => "<div>\n  <p>This is a <em>great</em> text</p>\n
> <table>\n<p>This is a _great_ text</p>\n</table>\n</div>\n"
> 
> So now we do recurse down into the first <p> tag. But what's up with
> the <table> tag? It seems to block recursion down.

It works fine if you use <div> instead of <table>. This is because the
HTML content model for <table> is 'raw' whereas for <div> it is 'block'
- raw content is not parsed any further but block content is.

This is done because the <table> element cannot contain kramdown block
or span elements.

Best regards,
  Thomas

From matt at tidbits.com  Mon Aug 27 20:30:29 2012
From: matt at tidbits.com (Matt Neuburg)
Date: Mon, 27 Aug 2012 13:30:29 -0700
Subject: [kramdown-users] block parsing not recursive?
In-Reply-To: <20120827221542.31d8b2ff@noweto>
References: <221F5257-ACC9-433F-ADBD-4B976265AD4B@tidbits.com>
	<20120827221542.31d8b2ff@noweto>
Message-ID: <4CCE2479-DE24-4805-9184-06818026866D@tidbits.com>

Okay, but given that I've got the HTML that I've got, is there any way to have kramdown come sweeping down through it and apply span-level and character-level transformations, like turning _great_ into <em>great</em> and making "stupid" quotes smart? m.

On Aug 27, 2012, at 1:15 PM, Thomas Leitner wrote:

> On 2012-08-12 08:33 -0700 Matt Neuburg wrote:
>> Shouldn't markdown="1" work recursively downward, so that _great_ is
>> parsed into <em>?
> 
> No, the markdown attribute is only applied to the content of the tag
> itself, not to other HTML tags found within.
> 
>> (2)
>> 
>> Okay, so let's try :parse_block_html instead:
>> 
>> s = <<END
>> <div markdown>
>> <p>This is a _great_ text</p>
>> <table>
>> <p>This is a _great_ text</p>
>> </table>
>> </div>
>> END
>> 
>> p Kramdown::Document.new(s, :parse_block_html => true).to_html
>> # => "<div>\n  <p>This is a <em>great</em> text</p>\n
>> <table>\n<p>This is a _great_ text</p>\n</table>\n</div>\n"
>> 
>> So now we do recurse down into the first <p> tag. But what's up with
>> the <table> tag? It seems to block recursion down.
> 
> It works fine if you use <div> instead of <table>. This is because the
> HTML content model for <table> is 'raw' whereas for <div> it is 'block'
> - raw content is not parsed any further but block content is.
> 
> This is done because the <table> element cannot contain kramdown block
> or span elements.
> 
> Best regards,
>  Thomas
> _______________________________________________
> kramdown-users mailing list
> kramdown-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/kramdown-users


From t_leitner at gmx.at  Tue Aug 28 07:37:45 2012
From: t_leitner at gmx.at (Thomas Leitner)
Date: Tue, 28 Aug 2012 09:37:45 +0200
Subject: [kramdown-users] block parsing not recursive?
In-Reply-To: <4CCE2479-DE24-4805-9184-06818026866D@tidbits.com>
References: <221F5257-ACC9-433F-ADBD-4B976265AD4B@tidbits.com>
	<20120827221542.31d8b2ff@noweto>
	<4CCE2479-DE24-4805-9184-06818026866D@tidbits.com>
Message-ID: <20120828093745.666ded55@noweto>

On 2012-08-27 13:30 -0700 Matt Neuburg wrote:
> Okay, but given that I've got the HTML that I've got, is there any
> way to have kramdown come sweeping down through it and apply
> span-level and character-level transformations, like turning _great_
> into <em>great</em> and making "stupid" quotes smart? m.

No, I don't think so because you want kramdown to have HTML as input
and selectively parse HTML tags with the kramdown span parser which is
not implemented.

However, it could surely be done by creating a custom HTML parser that
parses all HTML tags with the kramdown span parser.

Best regards,
  Thomas

From t_leitner at gmx.at  Fri Aug 31 14:17:53 2012
From: t_leitner at gmx.at (Thomas Leitner)
Date: Fri, 31 Aug 2012 16:17:53 +0200
Subject: [kramdown-users] Syntax for specifying code highlighting language |
 Github flavored code blocks style
Message-ID: <20120831161753.43178c94@noweto>

Hi everybody,

there is a [pull request][1] on Github which, among other things, wants
to add 1) support for Github flavored code style and 2) support for
setting the highlighting language on the delimiter line of a fenced code
block.

[1]: https://github.com/gettalong/kramdown/pull/15

I also want to talk 3) about the current way of setting the highlighting
language.


ad 1) kramdown already has a fenced code block style:

    ~~~
    some code here
    ~~~

Github flavored code blocks use a backtick instead:

    ```
    some code here
    ```

I personally don't think that it is necessary or even good in this
case to provide another syntax for fenced code blocks. Using the
backtick currently only works on the Github website itself, as far as I
know.

Also note that the kramdown (and php-markdown-extra and
python-markdown) fenced code blocks *do* work on Github, too!

So, what do you think?


ad 2) Providing the syntax highlighting language on the delimiter line
is a rather nice idea and not only supported by Github but also by
other markdown implementations (like python-markdown). It would look
like this:

    ~~~~~~ ruby
    class MyRuby
    end
    ~~~~~~~~~~~~

I would like to integrate this into kramdown -- does anyone have good
reasons for not using this syntax?


ad 3) The syntax highlighting language can currently be set by using an
IAL to specify the attribute `lang`. However, the `lang` attribute in
HTML elements is generally used for setting the natural language of the
text inside an element...

I'm for removing this collision by following the HTML5 way of
specifying the highlighting language, which is setting the class
`language-CODELANG` on the `<code>` element.

This would mean that this kramdown document:

    ~~~
    some code here
    ~~~
    {: .language-ruby .other attr="key"}

would be transformed to this HTML output (in case coderay was not used):

    <pre attr="key" class="other"><code class="language-ruby">some code here
    </code></pre>

Note that the `language-ruby` class is set on the `<code>` element and
not on the parent `<pre>` element!

This would be a backwards-incompatible change, what do you think?


Best regards,
  Thomas

From matt at tidbits.com  Fri Aug 31 16:07:23 2012
From: matt at tidbits.com (Matt Neuburg)
Date: Fri, 31 Aug 2012 09:07:23 -0700
Subject: [kramdown-users] Syntax for specifying code highlighting
	language | Github flavored code blocks style
In-Reply-To: <20120831161753.43178c94@noweto>
References: <20120831161753.43178c94@noweto>
Message-ID: <7748A8CF-754B-4D31-87B1-9D6BCACDAE08@tidbits.com>

I am someone who uses kramdown's fenced code block style and I agree with all three points: make no change to backticks, and go ahead and implement the other changes, even if there is breakage with "lang". m.

On Aug 31, 2012, at 7:17 AM, Thomas Leitner wrote:

> Hi everybody,
> 
> there is a [pull request][1] on Github which, among other things, wants
> to add 1) support for Github flavored code style and 2) support for
> setting the highlighting language on the delimiter line of a fenced code
> block.
> 
> [1]: https://github.com/gettalong/kramdown/pull/15
> 
> I also want to talk 3) about the current way of setting the highlighting
> language.
> 
> 
> ad 1) kramdown already has a fenced code block style:
> 
>    ~~~
>    some code here
>    ~~~
> 
> Github flavored code blocks use a backtick instead:
> 
>    ```
>    some code here
>    ```
> 
> I personally don't think that it is necessary or even good in this
> case to provide another syntax for fenced code blocks. Using the
> backtick currently only works on the Github website itself, as far as I
> know.
> 
> Also note that the kramdown (and php-markdown-extra and
> python-markdown) fenced code blocks *do* work on Github, too!
> 
> So, what do you think?
> 
> 
> ad 2) Providing the syntax highlighting language on the delimiter line
> is a rather nice idea and not only supported by Github but also by
> other markdown implementations (like python-markdown). It would look
> like this:
> 
>    ~~~~~~ ruby
>    class MyRuby
>    end
>    ~~~~~~~~~~~~
> 
> I would like to integrate this into kramdown -- does anyone have good
> reasons for not using this syntax?
> 
> 
> ad 3) The syntax highlighting language can currently be set by using an
> IAL to specify the attribute `lang`. However, the `lang` attribute in
> HTML elements is generally used for setting the natural language of the
> text inside an element...
> 
> I'm for removing this collision by following the HTML5 way of
> specifying the highlighting language, which is setting the class
> `language-CODELANG` on the `<code>` element.
> 
> This would mean that this kramdown document:
> 
>    ~~~
>    some code here
>    ~~~
>    {: .language-ruby .other attr="key"}
> 
> would be transformed to this HTML output (in case coderay was not used):
> 
>    <pre attr="key" class="other"><code class="language-ruby">some code here
>    </code></pre>
> 
> Note that the `language-ruby` class is set on the `<code>` element and
> not on the parent `<pre>` element!
> 
> This would be a backwards-incompatible change, what do you think?
> 
> 
> Best regards,
>  Thomas
> _______________________________________________
> kramdown-users mailing list
> kramdown-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/kramdown-users


From t_leitner at gmx.at  Fri Aug 31 16:43:56 2012
From: t_leitner at gmx.at (Thomas Leitner)
Date: Fri, 31 Aug 2012 18:43:56 +0200
Subject: [kramdown-users] [ANN] kramdown 0.13.8
Message-ID: <20120831184356.743721b8@noweto>

## About kramdown

kramdown (sic, not Kramdown or KramDown, just kramdown) is a *free*
GPL-licensed [Ruby](http://www.ruby-lang.org) library for parsing a
superset of Markdown. It is completely written in Ruby, supports
standard Markdown (with some minor modifications) and various
extensions that have been made popular by the PHP Markdown Extra
package and Maruku.

Homepage for installation instructions and documentation:
   http://kramdown.rubyforge.org


## kramdown 0.13.8 released

This release brings two new options (one for adjusting header levels
and the other for enabling/disabling coderay). And the usual bug fixes.

## Changes

* 2 minor changes

  - New option `header_offset` for offsetting all header levels
    (initial patch by Michal Till)
  - New option `enable_coderay` for enabling/disabling coderay (initial
    patch by Bran)

* 5 bug fixes

  - Reserved HTML characters in abbreviation titles are now correctly
    output (patch by Alex Tomlins)
  - Similar abbreviations (like CSS and CSS3) are now correctly parsed
  - Fixed bug [RF#29626]: Text of mailto-link was sometimes wrongly
    obfuscated (reported by B Wright)
  - Fixed known Ruby 1.9.3 problem with RakeTest task (patch by Gioele
    Barabucci)
  - Fixed double output of 'markdown' attribute on HTML elements in
    kramdown converter

* 1 documentation change

  - README file is now called README.md and uses kramdown syntax (patch
    by Bran)

[RF#29626]: http://rubyforge.org/tracker/index.php?func=detail&aid=29626&group_id=7403&atid=28673

From sunshine at sunshineco.com  Fri Aug 31 18:47:52 2012
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Fri, 31 Aug 2012 14:47:52 -0400
Subject: [kramdown-users] Syntax for specifying code highlighting
 language | Github flavored code blocks style
In-Reply-To: <7748A8CF-754B-4D31-87B1-9D6BCACDAE08@tidbits.com>
References: <20120831161753.43178c94@noweto>
	<7748A8CF-754B-4D31-87B1-9D6BCACDAE08@tidbits.com>
Message-ID: <CAPig+cTgKY9DiAi6SX3gqD5WFEzbiKLkrz60aR4a+VYuv7EKRw@mail.gmail.com>

1) [Github alternate fenced blocks]: I am not a fan of this and other
gratuitous differences from the norm, and my gut reaction is to reject
the change. The only small justification I can make for accepting it
is that it would increase the likelihood of kramdown being employed
locally to compose and preview a Markdown document which ultimately
will be viewed in rendered form on Github. Since Github documentation
[1] mentions only the ``` syntax, many people likely do not know that
it also accepts the ~~~ syntax.

2) [specify language on ~~~ line]: Seems like a reasonable convenience.

3) [syntax highlighting language]: kramdown has been around long
enough and (presumably) is widely enough used that
backward-incompatible changes should not be undertaken lightly. If I
understand correctly, the backward-incompatible change to which you
refer is that kramdown would no longer recognize lang=FOO specially.
In the interest of backward-compatibility, perhaps continue to
recognize lang=FOO if the following is true: .language-FOO is not
present and the FOO in lang=FOO does not seem to be a natural language
specification [2]. (Rough heuristic: If FOO contains a hyphen or is
only two characters in length, then it's probably a natural language
specification.)

[1]: http://github.github.com/github-flavored-markdown/
[2]: http://www.ietf.org/rfc/rfc1766.txt

-- ES


On Fri, Aug 31, 2012 at 12:07 PM, Matt Neuburg <matt at tidbits.com> wrote:
> I am someone who uses kramdown's fenced code block style and I agree with all three points: make no change to backticks, and go ahead and implement the other changes, even if there is breakage with "lang". m.
>
> On Aug 31, 2012, at 7:17 AM, Thomas Leitner wrote:
>
>> Hi everybody,
>>
>> there is a [pull request][1] on Github which, among other things, wants
>> to add 1) support for Github flavored code style and 2) support for
>> setting the highlighting language on the delimiter line of a fenced code
>> block.
>>
>> [1]: https://github.com/gettalong/kramdown/pull/15
>>
>> I also want to talk 3) about the current way of setting the highlighting
>> language.
>>
>>
>> ad 1) kramdown already has a fenced code block style:
>>
>>    ~~~
>>    some code here
>>    ~~~
>>
>> Github flavored code blocks use a backtick instead:
>>
>>    ```
>>    some code here
>>    ```
>>
>> I personally don't think that it is necessary or even good in this
>> case to provide another syntax for fenced code blocks. Using the
>> backtick currently only works on the Github website itself, as far as I
>> know.
>>
>> Also note that the kramdown (and php-markdown-extra and
>> python-markdown) fenced code blocks *do* work on Github, too!
>>
>> So, what do you think?
>>
>>
>> ad 2) Providing the syntax highlighting language on the delimiter line
>> is a rather nice idea and not only supported by Github but also by
>> other markdown implementations (like python-markdown). It would look
>> like this:
>>
>>    ~~~~~~ ruby
>>    class MyRuby
>>    end
>>    ~~~~~~~~~~~~
>>
>> I would like to integrate this into kramdown -- does anyone have good
>> reasons for not using this syntax?
>>
>>
>> ad 3) The syntax highlighting language can currently be set by using an
>> IAL to specify the attribute `lang`. However, the `lang` attribute in
>> HTML elements is generally used for setting the natural language of the
>> text inside an element...
>>
>> I'm for removing this collision by following the HTML5 way of
>> specifying the highlighting language, which is setting the class
>> `language-CODELANG` on the `<code>` element.
>>
>> This would mean that this kramdown document:
>>
>>    ~~~
>>    some code here
>>    ~~~
>>    {: .language-ruby .other attr="key"}
>>
>> would be transformed to this HTML output (in case coderay was not used):
>>
>>    <pre attr="key" class="other"><code class="language-ruby">some code here
>>    </code></pre>
>>
>> Note that the `language-ruby` class is set on the `<code>` element and
>> not on the parent `<pre>` element!
>>
>> This would be a backwards-incompatible change, what do you think?
>>
>>
>> Best regards,
>>  Thomas
>> _______________________________________________
>> kramdown-users mailing list
>> kramdown-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/kramdown-users
>
> _______________________________________________
> kramdown-users mailing list
> kramdown-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/kramdown-users