List items with multiple paragraphs do not work

[joliss]

With redcarpet 2.1.0, the following file produces different output than the reference implementation (John Gruber's markdown 1.0.1):

$ cat test.md 
* foo

  bar
$ redcarpet test.md
<ul>
<li>foo</li>
</ul>

<p>bar</p>
$ markdown test.md
<ul>
<li><p>foo</p>

<p>bar</p></li>
</ul>

[joliss]

I just noticed that according to http://daringfireball.net/projects/markdown/syntax#list, subsequent paragraphs should be indented by four spaces. The markdown binary obviously works with two spaces as well, but redcarpet requires four.

$ redcarpet 
* foo

    bar
^D
<ul>
<li><p>foo</p>

<p>bar</p></li>
</ul>

Should this be changed to match John Gruber's markdown implementation?

[vmg]

Good spotting, Jo. This has been in our internal issues list for a while. Do as they do, or do as they say?

...There are some tricky implementation issues when you change the soft limit for indentation from 4 spaces to 2, and you mix that with indented code blocks inside paragraphs. I'm looking into it.

[balupton]

This appears to be the same issue that has screwed most of my github project's readme rendering up.

For example, on the DocPad readme, I'm now getting this instead of this.

[philc]

Any update on this?

For reference, discount supports 2 spaces for paragraphs inside list items.

[eric-brechemier]

I feel like the spec makes more sense than observed behavior, because when I write:

API
---

  (...)

  Four functions are provided as arguments to the callback to interact with data and publish events
  within the confines of this shared symbolic space: 

  * get(name) - get the value of a property
  * set(name, value) - set the value of a property
  * publish(name, value) - publish an event and set the value of the property of the same name
  * subscribe(name, listener) - register a callback for the event of given name

  The get() and set() functions simply get and set properties in the module
  data, without publishing any event. Since the data object can also be
  accessed as '`this`' in the callback function, properties can also be set
  and retrieved directly.

  (...)

I do not expect the last item of the list to be rendered differently from the items before, and there is no visual hint to make me consider that all the contents after the list, at the same level of indentation as the whole list, will get inlined inside the last item of the list:

API

(...)

Four functions are provided as arguments to the callback to interact with data and publish events
within the confines of this shared symbolic space:

• get(name) - get the value of a property

• set(name, value) - set the value of a property

• publish(name, value) - publish an event and set the value of the property of the same name

• subscribe(name, listener) - register a callback for the event of given name

  The get() and set() functions simply get and set properties in the module
  data, without publishing any event. Since the data object can also be
  accessed as 'this' in the callback function, properties can also be set
  and retrieved directly.

  (...)

[eric-brechemier]

Would you like a pull request with a proposed solution? Unless there is something particular in the way?

[robin850]

If you are able to propose a pull request, go ahead! 😃 Thanks! We will eventually put some comments to help you improve your patch if it's necessary.

[eric-brechemier]

Thanks, I'll give it a try.

[joliss]

@eric-brechemier Hm, that's an interesting point. I guess even though the spec says "Normal paragraphs should not be indented with spaces or tabs", in practice people end up doing it sometimes (like in your README) because it reads nicely.

I haven't thought about the formal syntax rules much, but I'd expect the paragraph to be outside the list in this example (like you suggested):

  * List content

  Paragraph

but inside the list in this example:

* List content

  Paragraph

[eric-brechemier]

@joliss exactly. I have added a new unit test to describe the expected behavior.

[robin850]

Okay folks, @eric-brechemier has nicely fixed this problem in #317! Thank you everyone, this will be released in 3.1.0.