From t_leitner at gmx.at Sat Nov 21 03:04:32 2009
From: t_leitner at gmx.at (Thomas Leitner)
Date: Sat, 21 Nov 2009 09:04:32 +0100
Subject: [Kramdown-users] [ANN] kramdown 0.1.0 - first relase of fast,
pure Ruby Markdown parser
Message-ID: <20091121090432.73b901f6@noeato.local>
## kramdown 0.1.0 released
This is the first release of kramdown, yet-another-Markdown
parser/converter for Ruby, with the following features:
* Written in pure Ruby, no need to compile an extension (like BlueCloth
or rdiscount)
* Fast (current impl ~5x faster than Maruku, ~10x faster than
BlueFeather, although ~30x slower than native code like rdiscount)
* Strict syntax definition (special cases for which the original
Markdown page does not account for are explicitly listed and it is
shown how kramdown parses them - see the [Syntax] page)
* Supports common Markdown extension (similar to Maruku)
[Syntax]: http://kramdown.rubyforge.org/syntax.html
## About kramdown
kramdown is a *free* GPL-licensed [Ruby](http://www.ruby-lang.org)
library for parsing Markdown-like syntax. 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
From t_leitner at gmx.at Sat Nov 21 03:05:28 2009
From: t_leitner at gmx.at (Thomas Leitner)
Date: Sat, 21 Nov 2009 17:05:28 +0900
Subject: [Kramdown-users] [ANN] kramdown 0.1.0 - first relase of fast,
pure Ruby Markdown parser
Message-ID: <20091121090432.73b901f6@noeato.local>
## kramdown 0.1.0 released
This is the first release of kramdown, yet-another-Markdown
parser/converter for Ruby, with the following features:
* Written in pure Ruby, no need to compile an extension (like BlueCloth
or rdiscount)
* Fast (current impl ~5x faster than Maruku, ~10x faster than
BlueFeather, although ~30x slower than native code like rdiscount)
* Strict syntax definition (special cases for which the original
Markdown page does not account for are explicitly listed and it is
shown how kramdown parses them - see the [Syntax] page)
* Supports common Markdown extension (similar to Maruku)
[Syntax]: http://kramdown.rubyforge.org/syntax.html
## About kramdown
kramdown is a *free* GPL-licensed [Ruby](http://www.ruby-lang.org)
library for parsing Markdown-like syntax. 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
From sunshine at sunshineco.com Tue Nov 24 11:18:45 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Tue, 24 Nov 2009 11:18:45 -0500
Subject: [Kramdown-users] HTML span clarification
Message-ID: <4B0C0765.5080307@sunshineco.com>
Hi Thomas,
The Kramdown documentation for HTML spans
(http://kramdown.rubyforge.org/syntax.html#html-spans) states:
"Span level HTML tags ... have to be preceded by at least one non
whitespace character on the same line so that kramdown correctly
recognizes them as span level element and not as block level element."
If I read this correctly, then the following HTML {a}...{/a} element at
the start of a paragraph should not be recognized as a span element.
(HTML angle delimiters replaced by { and } to pacify broken email clients.)
{a href="/" title="Product"}Product{/a} was released.
Download it _now_.
Nevertheless, Kramdown produces the expected (and desired) output;
{p}{a href="/" title="Product"}Product{/a} was released.
Download it {em}now{/em}.{/p}
This output seems to contradict the documentation. On the other hand, I
repeatedly run into situations where this sort of situation arises, so
the present Kramdown behavior is desirable. Maruku utterly fails with
this input and requires ugly work-arounds.
-- ES
From sunshine at sunshineco.com Tue Nov 24 11:04:15 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Tue, 24 Nov 2009 11:04:15 -0500
Subject: [Kramdown-users] Expected HTML span behavior?
Message-ID: <4B0C03FF.4000507@sunshineco.com>
Hi Thomas,
What is the expected behavior of Kramdown when an HTML span is split
over multiple lines within a quoted attribute string? For instance, say
that an editor has performed line-wrapping on some Markdown input with
embedded HTML so that the input to Kramdown is as follows. (I replaced
the HTML angle delimiters with { and } to pacify broken email clients.)
Link: {a href="/" title="Foo
Bar"}Foo Bar{/a}
When fed through Kramdown, this produces the startling:
{p}Link: <a href="/" title="Foo
Bar">Foo Bar</a>{/p}
Rather than the expected:
{p}Link: {a href="/" title="Foo Bar"}Foo Bar{/a}{/p}
Or perhaps, though unlikely:
{p}Link: {a href="/" title="Foo
Bar"}Foo Bar{/a}{/p}
The documentation at
http://kramdown.rubyforge.org/syntax.html#html-spans does not seem to
cover this case.
-- ES
From t_leitner at gmx.at Tue Nov 24 15:28:08 2009
From: t_leitner at gmx.at (Thomas Leitner)
Date: Tue, 24 Nov 2009 21:28:08 +0100
Subject: [Kramdown-users] HTML span clarification
In-Reply-To: <4B0C0765.5080307@sunshineco.com>
References: <4B0C0765.5080307@sunshineco.com>
Message-ID: <20091124212808.17d4a665@noeato.local>
Hi Eric,
> {a href="/" title="Product"}Product{/a} was released.
> Download it _now_.
>
> Nevertheless, Kramdown produces the expected (and desired) output;
>
> {p}{a href="/" title="Product"}Product{/a} was released.
> Download it {em}now{/em}.{/p}
>
> This output seems to contradict the documentation. On the other hand,
> I repeatedly run into situations where this sort of situation arises,
> so the present Kramdown behavior is desirable. Maruku utterly fails
> with this input and requires ugly work-arounds.
the HTML block and span sections in the syntax documentation are not
very clear on this, I know. I'm currently refactoring the HTML parsing
code since it is about the ugliest part in the parser ;-) - the syntax
documentation will be adpated accordingly.
Regarding your example above: the syntax documentation is false in this
regard, the actual code is and will be right!
There are still some situations where the HTML parsing code doesn't do
quite the "right thing" although it currently also much flexibility
(e.g. tables and some special cases with the script tag don't work
right now).
-- Thomas
From t_leitner at gmx.at Tue Nov 24 15:40:40 2009
From: t_leitner at gmx.at (Thomas Leitner)
Date: Tue, 24 Nov 2009 21:40:40 +0100
Subject: [Kramdown-users] Expected HTML span behavior?
In-Reply-To: <4B0C03FF.4000507@sunshineco.com>
References: <4B0C03FF.4000507@sunshineco.com>
Message-ID: <20091124214040.755d294f@noeato.local>
> Rather than the expected:
>
> {p}Link: {a href="/" title="Foo Bar"}Foo Bar{/a}{/p}
>
> Or perhaps, though unlikely:
>
> {p}Link: {a href="/" title="Foo
> Bar"}Foo Bar{/a}{/p}
Since the syntax documentation is still in a state of flux, some cases
are not described. As for your example, I also think that kramdown
should output one of the above. I have added this to my TODO list -
thanks!
-- Thomas
From sunshine at sunshineco.com Tue Nov 24 21:15:56 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Tue, 24 Nov 2009 21:15:56 -0500
Subject: [Kramdown-users] Expected HTML span behavior?
In-Reply-To: <20091124214040.755d294f@noeato.local>
References: <4B0C03FF.4000507@sunshineco.com>
<20091124214040.755d294f@noeato.local>
Message-ID: <4B0C935C.6090700@sunshineco.com>
Hi Thomas,
Thomas Leitner wrote:
>> Rather than the expected:
>> {p}Link: {a href="/" title="Foo Bar"}Foo Bar{/a}{/p}
>> Or perhaps, though unlikely:
>> {p}Link: {a href="/" title="Foo
>> Bar"}Foo Bar{/a}{/p}
> Since the syntax documentation is still in a state of flux, some cases
> are not described. As for your example, I also think that kramdown
> should output one of the above. I have added this to my TODO list -
> thanks!
Different browsers treat a newline in the the 'title' attribute
differently. (Firefox folds out the newline in 'title' but Chrome and
IE8 respect it.) Perhaps, therefore, it would be best for Kramdown to
normalize attribute strings to the first "expected" output, where the
newline is folded out, rather than the second.
On the one hand, though, it can be argued that it is not Kramdown's
responsibility to appease different browsers, so folding out the newline
should not be Kramdown's responsibility. On the other hand, Kramdown
already appears to be manipulating the HTML element attributes
(alphabetizing them?), so additionally folding out embedded newlines
from attribute values is not so far fetched.
-- ES
From sunshine at sunshineco.com Tue Nov 24 21:31:59 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Tue, 24 Nov 2009 21:31:59 -0500
Subject: [Kramdown-users] HTML span clarification
In-Reply-To: <20091124212808.17d4a665@noeato.local>
References: <4B0C0765.5080307@sunshineco.com>
<20091124212808.17d4a665@noeato.local>
Message-ID: <4B0C971F.3060302@sunshineco.com>
Hi Thomas,
Thomas Leitner wrote:
>> {a href="/" title="Product"}Product{/a} was released.
>> Download it _now_.
>> Nevertheless, Kramdown produces the expected (and desired) output;
>> {p}{a href="/" title="Product"}Product{/a} was released.
>> Download it {em}now{/em}.{/p}
> Regarding your example above: the syntax documentation is false in this
> regard, the actual code is and will be right!
I am glad to hear that the present behavior is correct and intentional.
This sort of situation arises often enough with ERB -> Markdown
pipelines that it would be painful if span-level HTML elements were not
correctly recognized as such.
-- ES
From sunshine at sunshineco.com Tue Nov 24 22:44:02 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Tue, 24 Nov 2009 22:44:02 -0500
Subject: [Kramdown-users] Broken mailto: obfuscation
Message-ID: <4B0CA802.3090304@sunshineco.com>
Hi Thomas,
Given the following Markdown input with embedded HTML:
Mail: My Name
kramdown's email obfuscation badly corrupts it to:
Mail: a href
="mailto:me�
64;example.com
?subject=Fo
11;"My Name</a>
which renders in the browser literally as:
Mail: [a href="mailto:me at example.com?subject=Foo"]My Name
I added the [ brackets ] to show the clickable portion of the rendered
output. It should render as:
Mail: [My Name]
-- ES
From sunshine at sunshineco.com Tue Nov 24 23:01:40 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Tue, 24 Nov 2009 23:01:40 -0500
Subject: [Kramdown-users] Broken mailto: obfuscation
In-Reply-To: <4B0CA802.3090304@sunshineco.com>
References: <4B0CA802.3090304@sunshineco.com>
Message-ID: <4B0CAC24.30706@sunshineco.com>
After digging further into the kramdown implementation, I see that the
corruption problem actually lies with the 'autolink' handling rather
than the email obfuscation code.
-- ES
Eric Sunshine wrote:
> Hi Thomas,
>
> Given the following Markdown input with embedded HTML:
>
> Mail: My Name
>
> kramdown's email obfuscation badly corrupts it to:
>
> Mail: a href
> ="mailto:me�
> 64;example.com
> ?subject=Fo
> 11;"My Name</a>
>
> which renders in the browser literally as:
>
> Mail: [a href="mailto:me at example.com?subject=Foo"]My Name
>
> I added the [ brackets ] to show the clickable portion of the rendered
> output. It should render as:
>
> Mail: [My Name]
>
> -- ES
> _______________________________________________
> Kramdown-users mailing list
> Kramdown-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/kramdown-users
>
From t_leitner at gmx.at Wed Nov 25 09:41:55 2009
From: t_leitner at gmx.at (Thomas Leitner)
Date: Wed, 25 Nov 2009 15:41:55 +0100
Subject: [Kramdown-users] Broken mailto: obfuscation
In-Reply-To: <4B0CAC24.30706@sunshineco.com>
References: <4B0CA802.3090304@sunshineco.com> <4B0CAC24.30706@sunshineco.com>
Message-ID: <20091125154155.13e060a0@noeato.local>
> After digging further into the kramdown implementation, I see that
> the corruption problem actually lies with the 'autolink' handling
> rather than the email obfuscation code.
Thanks for reporting this, I have fixed this in the repo.
-- Thomas
From sunshine at sunshineco.com Thu Nov 26 20:32:47 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Thu, 26 Nov 2009 20:32:47 -0500
Subject: [Kramdown-users] Definition lists and tables
Message-ID: <4B0F2C3F.5080403@sunshineco.com>
Hi Thomas,
Are there plans to support PHP Markdown Extra definition lists
(...
) and tables ()? Although I use tables
rarely, definition lists crop up with some frequency, and their absence
in kramdown is problematic.
-- ES
From sunshine at sunshineco.com Thu Nov 26 21:48:22 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Thu, 26 Nov 2009 21:48:22 -0500
Subject: [Kramdown-users] Markdown processing within HTML
Message-ID: <4B0F3DF6.2050406@sunshineco.com>
Hi Thomas,
I am finding that kramdown's default processing of Markdown within
block-level HTML elements tends to be painful. For instance, given the
legitimate embedded HTML:
- Foo
- cow
kramdown emits the following invalid output:
- Foo
- cow
By invalid, I mean that this output is structurally incorrect and will
not pass w3c.org validation. It seems unfortunate that one should have
to litter {::nokramdown:} throughout the document to avoid such
situations. The original Markdown's decision to inhibit processing
within block-level elements seems far less intrusive.
Even the simple case of ...
being transformed into
by kramdown by default is potentially undesirable.
Typically, when going to the effort of manually coding a ...
block, one typically wants it preserved as typed, without the extra
block-level element (...
) being inserted.
Rather than performing Markdown processing by default in block-level
elements, perhaps it might make more sense to have a complementary
{::kramdown:} which re-enables processing with the element. Alternately,
something skin to Maruku's ...
(for any
block-level element) might be suitable.
-- ES
From t_leitner at gmx.at Fri Nov 27 02:15:57 2009
From: t_leitner at gmx.at (Thomas Leitner)
Date: Fri, 27 Nov 2009 08:15:57 +0100
Subject: [Kramdown-users] Definition lists and tables
In-Reply-To: <4B0F2C3F.5080403@sunshineco.com>
References: <4B0F2C3F.5080403@sunshineco.com>
Message-ID: <20091127081557.6834e69e@noeato>
> Are there plans to support PHP Markdown Extra definition lists
> (...
) and tables ()? Although I use tables
> rarely, definition lists crop up with some frequency, and their
> absence in kramdown is problematic.
Definition lists are on my TODO list and will be implemented in a future
version but I can't give you a timeline for it. However, I reckon I will
find the time to implement definition lists this year.
-- Thomas
From t_leitner at gmx.at Fri Nov 27 02:26:00 2009
From: t_leitner at gmx.at (Thomas Leitner)
Date: Fri, 27 Nov 2009 08:26:00 +0100
Subject: [Kramdown-users] Markdown processing within HTML
In-Reply-To: <4B0F3DF6.2050406@sunshineco.com>
References: <4B0F3DF6.2050406@sunshineco.com>
Message-ID: <20091127082600.01f0aa43@noeato>
> I am finding that kramdown's default processing of Markdown within
> block-level HTML elements tends to be painful. For instance, given
> the legitimate embedded HTML:
>
>
>
> - Foo
> - cow
>
>
> kramdown emits the following invalid output:
>
>
>
> - Foo
> - cow
>
I have added li, dt and dd to the list of HTML tags recognized as block
level HTML tags. With this change the above works as expected.
> Even the simple case of ...
being transformed into
> by kramdown by default is potentially
> undesirable. Typically, when going to the effort of manually coding a
> ...
block, one typically wants it preserved as typed,
> without the extra block-level element (...
) being inserted.
>
> Rather than performing Markdown processing by default in block-level
> elements, perhaps it might make more sense to have a complementary
> {::kramdown:} which re-enables processing with the element.
> Alternately, something skin to Maruku's ...
> (for any block-level element) might be suitable.
The implementation of the markdown="0|1|block|span" feature is on my
TODO list and will make it into the 0.2.0 release. I will also add an
option for setting whether block and span HTML tags are automatically
parsed by kramdown.
Regarding the {::kramdown:} element: since kramdown syntax will then
not be parsed in the element, the {::kramdown:} element won't also be
recognized...
I will probably just change the default
kramdown-syntax-in-HTML-parsing to false.
-- Thomas
From t_leitner at gmx.at Fri Nov 27 04:19:30 2009
From: t_leitner at gmx.at (Thomas Leitner)
Date: Fri, 27 Nov 2009 10:19:30 +0100
Subject: [Kramdown-users] Markdown processing within HTML
In-Reply-To: <20091127082600.01f0aa43@noeato>
References: <4B0F3DF6.2050406@sunshineco.com> <20091127082600.01f0aa43@noeato>
Message-ID: <20091127101930.06e73014@noeato>
> The implementation of the markdown="0|1|block|span" feature is on my
> TODO list and will make it into the 0.2.0 release. I will also add an
> option for setting whether block and span HTML tags are automatically
> parsed by kramdown.
>
>
>
> I will probably just change the default
> kramdown-syntax-in-HTML-parsing to false.
I have implemented the changes which are available at the github
repository http://github.com/gettalong/kramdown. Could you please try
out this updated version and tell me if it works like expected?
-- Thomas
From sunshine at sunshineco.com Fri Nov 27 08:45:30 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Fri, 27 Nov 2009 08:45:30 -0500
Subject: [Kramdown-users] Markdown processing within HTML
In-Reply-To: <20091127082600.01f0aa43@noeato>
References: <4B0F3DF6.2050406@sunshineco.com> <20091127082600.01f0aa43@noeato>
Message-ID: <4B0FD7FA.2060409@sunshineco.com>
Hi Thomas,
Thomas Leitner wrote:
>> Rather than performing Markdown processing by default in block-level
>> elements, perhaps it might make more sense to have a complementary
>> {::kramdown:} which re-enables processing with the element.
>> Alternately, something skin to Maruku's ...
>> (for any block-level element) might be suitable.
> Regarding the {::kramdown:} element: since kramdown syntax will then
> not be parsed in the element, the {::kramdown:} element won't also be
> recognized...
I was thinking also that {::kramdown:} could be wrapped around the
element to force Markdown processing within, in which case this could
work. On the other hand, it's not important if processing is disabled by
default for block-level elements and the option is
implemented.
-- ES
From sunshine at sunshineco.com Fri Nov 27 08:52:11 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Fri, 27 Nov 2009 08:52:11 -0500
Subject: [Kramdown-users] Markdown processing within HTML
In-Reply-To: <20091127101930.06e73014@noeato>
References: <4B0F3DF6.2050406@sunshineco.com> <20091127082600.01f0aa43@noeato>
<20091127101930.06e73014@noeato>
Message-ID: <4B0FD98B.4010904@sunshineco.com>
Thomas Leitner wrote:
>> The implementation of the markdown="0|1|block|span" feature is on my
>> TODO list and will make it into the 0.2.0 release. I will also add an
>> option for setting whether block and span HTML tags are automatically
>> parsed by kramdown.
>> I will probably just change the default
>> kramdown-syntax-in-HTML-parsing to false.
> I have implemented the changes which are available at the github
> repository http://github.com/gettalong/kramdown. Could you please try
> out this updated version and tell me if it works like expected?
Thanks, Thomas. I will check it out shortly.
One concern, however, is that this new behavior also differs from
original Markdown in which processing is disabled for block-level HTML
elements but enabled for span-level elements
(http://daringfireball.net/projects/markdown/syntax#html). In order to
avoid arbitrary inconsistencies with original Markdown, it perhaps would
be best for kramdown processing to remain enabled by default in
span-level elements.
-- ES
From sunshine at sunshineco.com Fri Nov 27 09:46:57 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Fri, 27 Nov 2009 09:46:57 -0500
Subject: [Kramdown-users] Broken mailto: obfuscation
In-Reply-To: <20091125154155.13e060a0@noeato.local>
References: <4B0CA802.3090304@sunshineco.com> <4B0CAC24.30706@sunshineco.com>
<20091125154155.13e060a0@noeato.local>
Message-ID: <4B0FE661.4050509@sunshineco.com>
Thomas Leitner wrote:
>> After digging further into the kramdown implementation, I see that
>> the corruption problem actually lies with the 'autolink' handling
>> rather than the email obfuscation code.
> Thanks for reporting this, I have fixed this in the repo.
Tested with the repository version. Works correctly. Thanks.
-- ES
From sunshine at sunshineco.com Fri Nov 27 09:55:01 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Fri, 27 Nov 2009 09:55:01 -0500
Subject: [Kramdown-users] Expected HTML span behavior?
In-Reply-To: <20091127080959.2470462b@noeato>
References: <4B0C03FF.4000507@sunshineco.com> <20091124214040.755d294f@noeato.local> <4B0C935C.6090700@sunshineco.com>
<20091127080959.2470462b@noeato>
Message-ID: <4B0FE845.6080106@sunshineco.com>
Thomas Leitner wrote:
>> Different browsers treat a newline in the the 'title' attribute
>> differently. (Firefox folds out the newline in 'title' but Chrome and
>> IE8 respect it.) Perhaps, therefore, it would be best for Kramdown to
>> normalize attribute strings to the first "expected" output, where the
>> newline is folded out, rather than the second.
> One or more consecutive new lines in HTML attributes are now replaced
> by a single space.
Works correctly with repository version (commit
3966cac694de1a58f8472f5366da0a1eb1b60475). Thank you.
-- ES
From sunshine at sunshineco.com Fri Nov 27 10:53:43 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Fri, 27 Nov 2009 10:53:43 -0500
Subject: [Kramdown-users] Markdown processing within HTML
In-Reply-To: <20091127082600.01f0aa43@noeato>
References: <4B0F3DF6.2050406@sunshineco.com> <20091127082600.01f0aa43@noeato>
Message-ID: <4B0FF607.7060502@sunshineco.com>
Hi Thomas,
Thomas Leitner wrote:
>> For instance, given the legitimate embedded HTML:
>>
>>
>> - Foo
>> - cow
>>
> I have added li, dt and dd to the list of HTML tags recognized as block
> level HTML tags. With this change the above works as expected.
Using repository commit 3966cac694de1a58f8472f5366da0a1eb1b60475, I was
able to remove all the ugly {::nokramdown:} invocations. Thank you.
>> > The implementation of the markdown="0|1|block|span" feature is on my
>> > TODO list and will make it into the 0.2.0 release. I will also add an
>> > option for setting whether block and span HTML tags are automatically
>> > parsed by kramdown.
>> > I will probably just change the default
>> > kramdown-syntax-in-HTML-parsing to false.
> I have implemented the changes which are available at the github
> repository http://github.com/gettalong/kramdown. Could you please try
> out this updated version and tell me if it works like expected?
Things are looking a lot better with the latest commits. I did, however,
notice a problem where it was not possible to re-enable Markdown
processing in one of my test cases:
- Foo
-
Paragraph 1
Paragraph 2
Paragraph 3
For this input, I would have expected the w3c.org-valid output:
- Foo
-
Paragraph 1
Paragraph 2
Paragraph 3
but kramdown instead emitted:
- Foo
-
Paragraph 1
Paragraph 2
Paragraph 3
Even with {::kdoptions:: parse_block_html="true"} and/or {::kdoptions::
parse_span_html="true"}, kramdown stubbornly refused to process the
paragraphs in the above ... element.
Experience would suggest that multi-paragraph .. and
.. are not entirely uncommon, so one can foresee demand for
this to work as expected (especially in the absence of built-in kramdown
definition list support).
-- ES
From sunshine at sunshineco.com Fri Nov 27 11:56:49 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Fri, 27 Nov 2009 11:56:49 -0500
Subject: [Kramdown-users] Suggest rename 'nokramdown' to 'nomarkdown'
Message-ID: <4B1004D1.3030205@sunshineco.com>
Suggestion: Rename {::nokramdown:} to {::nomarkdown:}. The concept of
disabling markdown processing within a block is sufficiently general
that this sort of directive is something which other Markdown processors
could adopt. By renaming it to 'nomarkdown', adoption is more likely and
text marked up in this fashion is more transportable. (Perhaps still
recognize 'nokramdown' for backward compatibility.}
Even the {::kdoptions::} idea is sufficiently general that it could be
renamed to {::markdownoptions::} making it simpler for other Markdown
processors to adopt the facility. (Options not recognized by a
particular implementation would be ignored, or emit an optional warning.)
-- ES
From t_leitner at gmx.at Fri Nov 27 14:15:40 2009
From: t_leitner at gmx.at (Thomas Leitner)
Date: Fri, 27 Nov 2009 20:15:40 +0100
Subject: [Kramdown-users] Suggest rename 'nokramdown' to 'nomarkdown'
In-Reply-To: <4B1004D1.3030205@sunshineco.com>
References: <4B1004D1.3030205@sunshineco.com>
Message-ID: <20091127201540.4493cb28@noeato>
> Suggestion: Rename {::nokramdown:} to {::nomarkdown:}. The concept of
> disabling markdown processing within a block is sufficiently general
> that this sort of directive is something which other Markdown
> processors could adopt. By renaming it to 'nomarkdown', adoption is
> more likely and text marked up in this fashion is more transportable.
> (Perhaps still recognize 'nokramdown' for backward compatibility.}
>
> Even the {::kdoptions::} idea is sufficiently general that it could
> be renamed to {::markdownoptions::} making it simpler for other
> Markdown processors to adopt the facility. (Options not recognized by
> a particular implementation would be ignored, or emit an optional
> warning.)
Valid points, thanks for mentioning them!
When writing the syntax documentation for kramdown I started with what
I liked from Markdown and added the extra features found in other
processors. Only later on I realized that I should try to make the
basic syntax of kramdown more compatible with standard Markdown. And I
should probably make it more clear in the documentation that kramdown
is a Markdown-superset processor, not a completely new format.
-- Thomas
From sunshine at sunshineco.com Sun Nov 29 17:56:29 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Sun, 29 Nov 2009 17:56:29 -0500
Subject: [Kramdown-users] Markdown processing within HTML
In-Reply-To: <4B0FF607.7060502@sunshineco.com>
References: <4B0F3DF6.2050406@sunshineco.com> <20091127082600.01f0aa43@noeato>
<4B0FF607.7060502@sunshineco.com>
Message-ID: <4B12FC1D.5070801@sunshineco.com>
Further observations on this thread (see quoted message below for
original problem description): Apparently, Markdown processing is in
fact active to some extent in the .. element. Given the input:
- Foo
-
Paragraph *1*
Paragraph **2**
Paragraph 3 [link](http://example.com/)
kramdown emits:
- Foo
-
Paragraph 1
Paragraph 2
Paragraph 3 link
So, it did correctly recognize and emit some directives (, ,
), but did not recognize multiple paragraphs.
-- ES
Eric Sunshine wrote:
> Things are looking a lot better with the latest commits. I did, however,
> notice a problem where it was not possible to re-enable Markdown
> processing in one of my test cases:
>
>
> - Foo
> -
> Paragraph 1
>
> Paragraph 2
>
> Paragraph 3
>
>
>
> For this input, I would have expected the w3c.org-valid output:
>
>
> - Foo
> -
>
Paragraph 1
> Paragraph 2
> Paragraph 3
>
>
>
> but kramdown instead emitted:
>
>
> - Foo
> -
> Paragraph 1
>
> Paragraph 2
>
> Paragraph 3
>
>
>
> Even with {::kdoptions:: parse_block_html="true"} and/or {::kdoptions::
> parse_span_html="true"}, kramdown stubbornly refused to process the
> paragraphs in the above ... element.
>
> Experience would suggest that multi-paragraph .. and
> .. are not entirely uncommon, so one can foresee demand for
> this to work as expected (especially in the absence of built-in kramdown
> definition list support).
>
> -- ES
> _______________________________________________
> Kramdown-users mailing list
> Kramdown-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/kramdown-users
>
From sunshine at sunshineco.com Mon Nov 30 14:07:31 2009
From: sunshine at sunshineco.com (Eric Sunshine)
Date: Mon, 30 Nov 2009 14:07:31 -0500
Subject: [Kramdown-users] Suggest rename 'nokramdown' to 'nomarkdown'
In-Reply-To: <20091127201540.4493cb28@noeato>
References: <4B1004D1.3030205@sunshineco.com> <20091127201540.4493cb28@noeato>
Message-ID: <4B1417F3.6000704@sunshineco.com>
Hi Thomas,
Note that there is a typographical error in doc/syntax.page (commit
7329d179c7a4ff44e99c39dc19a8532d0f203315) where "nomarkdown" is spelled
incorrectly as "nomarkown" (missing 'd').
-- ES
Thomas Leitner wrote:
>> Suggestion: Rename {::nokramdown:} to {::nomarkdown:}. The concept of
>> disabling markdown processing within a block is sufficiently general
>> that this sort of directive is something which other Markdown
>> processors could adopt. By renaming it to 'nomarkdown', adoption is
>> more likely and text marked up in this fashion is more transportable.
>> (Perhaps still recognize 'nokramdown' for backward compatibility.}
>>
>> Even the {::kdoptions::} idea is sufficiently general that it could
>> be renamed to {::markdownoptions::} making it simpler for other
>> Markdown processors to adopt the facility. (Options not recognized by
>> a particular implementation would be ignored, or emit an optional
>> warning.)
>
> Valid points, thanks for mentioning them!
>
> When writing the syntax documentation for kramdown I started with what
> I liked from Markdown and added the extra features found in other
> processors. Only later on I realized that I should try to make the
> basic syntax of kramdown more compatible with standard Markdown. And I
> should probably make it more clear in the documentation that kramdown
> is a Markdown-superset processor, not a completely new format.
>
> -- Thomas
> _______________________________________________
> Kramdown-users mailing list
> Kramdown-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/kramdown-users
>