Michael Granger <ged / faeriemud.org> wrote:

> > BlueCloth.new("I'm testing  ").to_html
> > #=> =====
> > <p>I'm testing<br/>
> > </p>
> >
> > That <br/> is functionally significant (it causes extra vertical
> > whitespace), and Perl Markdown does *not* generate it. BlueCloth is
> > apparently treating the extra spaces at the end of the input string as
> > somehow significant.
> 
> Right, I'm aware of BR's functional significance in HTML. The Syntax
> documentation cited above states (under the Paragraphs and Line Breaks
> section):
> 
>    "When you do want to insert a <br /> break tag using
>     Markdown, you end a line with two or more spaces, then
>     type return."
> 
> Your test case doesn't have a trailing newline, and the Syntax  
> document doesn't say what should happen with a line that ends with two
> spaces at the end of a document

Right, but I was just simplifying; in real life the example did have two
trailing newlines. In other words, the way I discovered this issue was
from a situation more like the following:

require 'rubygems'
require 'bluecloth'
puts BlueCloth.new("
two spaces follow  
two spaces follow  

done
").to_html

Markdown puts a <br> after the first line but not after the second.
Discount puts a <br> after both. 

> not. Perhaps a case could be made to include a test for the break tag
> rule only applying to the middle of a paragraph in MarkdownTest

Yes, I think so. But really, that case isn't worth worrying about too
much; the two spaces were actually just a mistake, and easily
eliminated.

> > This next one is a little more involved; I'll use a here document to
> > display my input text:
> >
> > s = <<END
> > * testing
> >
> >        pre
> >
> > more li
> > [...]
> > As you can see, the last <p> block (containing "more li") *is* part of
> > the <li> block. Since that is what Perl Markdown does, and since I
> > have
> > lots of text that relies upon Markdown behaving in that way, I  
> > naturally
> > incline to the view that that is the "correct" answer and that
> > BlueCloth's output is "wrong".
> 
> You are certainly welcome to your own view, but again, referring to  
> the Syntax Documentation:
> 
>    "List items may consist of multiple paragraphs. Each subsequent
>     paragraph in a list item must be indented by either 4 spaces
>     or one tab:"
> 
> Your "more li" line is *not* indented by either 4 spaces or one tab

That's true, but what would be really helpful is if you would tell me
what text to start with to generate the result I'm after. Here's the
schema for the desired result:

<ul><li>
<p>testing</p>
<pre><code>li</code></pre>
<p>more li</p>
</li></ul>

I can add spaces to cause the "more li" to be included in the <li>
block, but I haven't found a way to do that *and* wrap "more li" in a
<p> block with BlueCloth.

So, for example, this works the way I expect:

puts BlueCloth.new("
* testing

        pre

    more li

    still more li

done").to_html

In that example, both "more li" and "still more li" are each wrapped in
a <p> tag and they are both within the <li> tag that started in the
first line. But if I delete "still more li", I can't get "more li" all
by itself to be wrapped in a <p> tag and within the <li> tag. So surely
Discount here disagrees with itself in a way that could be taken as
troublesome, on the basis of simple considerations of consistency. If
you eliminate the "still more li" line, I am obeying the lines you
quote: "Each subsequent paragraph in a list item must be indented by ...
4 spaces"; yet I am not getting a paragraph in the output.

> out by the creator of Markdown (the syntax), which BlueCloth does. I'm
> certainly not suggesting that you should give up your reliance on  
> Markdown.pl's output if you don't mind forking a Perl interpreter  
> every time you want to transform your text to HTML.

Well, I do mind it. That's why I want to switch away! But in order to do
so, I have to be able to generate the HTML I'm already generating.

> If it isn't useful to you, either  
> keep doing what does work for you or consider contributing some value
> back to the system by providing fixes. Anything else is just sound and
> fury.

So there's no such thing as a conceivably legitimate bug report, and
there's no such thing as asking for help? m.

-- 
matt neuburg, phd = matt / tidbits.com, http://www.tidbits.com/matt/
Leopard - http://www.takecontrolbooks.com/leopard-customizing.html
AppleScript - http://www.amazon.com/gp/product/0596102119
Read TidBITS! It's free and smart. http://www.tidbits.com