Invalid nested list rendering

[kofalt]

In a nested mixed-type list, numbered lists do not render correctly, and indentation is missing.
Screenshot of the problem (expected vs actual):

The example input:

1. Numbered item 1
 * Sub-list
1. Numbered item 2
 * Sub-list
1. Numbered item 3
 * Sub-list

Results in the following output:

<ol>
    <li>Numbered item 1</li>
</ol>
<ul>
    <li>Sub-list</li>
</ul>
<ol>
    <li>Numbered item 2</li>
</ol>
<ul>
    <li>Sub-list</li>
</ul>
<ol>
    <li>Numbered item 3</li>
</ol>
<ul>
    <li>Sub-list</li>
</ul></div>

Compare with expected output (using Github as an example):

<ol>
    <li>Numbered item 1
        <ul>
            <li>Sub-list</li>
        </ul>
    </li>
    <li>Numbered item 2
        <ul>
            <li>Sub-list</li>
        </ul>
    </li>
    <li>Numbered item 3
        <ul>
            <li>Sub-list</li>
        </ul>
    </li>
</ol>

In both HTML cases I changed whitespace indentation to be consistent for comparison.
Note that changing the input's sub-list indentation from spaces to tabs works.

Originally reported as a bug in Atlassian Stash: https://jira.atlassian.com/browse/STASH-3702

[jirutka]

You must use at least 4 spaces for each level of nested list indentation.

[sirthias]

Closing as invalid

[kofalt]

Sounds good. As a side note, Github interprets a single space as indentation, but I'm assuming that in this case you're following the Daring Fireball example instead? Is this specified formally anywhere?

Just curious where & how choices between Markdown/Github-Flavored Markdown/etc are made.

[michaelmior]

Any particular reason not to support < 4 spaces for indentation?

[sirthias]

@michaelmior Yes, the Markdown "spec".

[michaelmior]

My point was that it seems that Pegdown could render valid documents as per the original Markdown spec, but also support a varying number of spaces without losing conformity.

[stavytskyi]

I agree with @michaelmior. I think Github markdown spec is more frequently used as !default markdown.

[jirutka]

The original Markdown “spec” from John Gruber is very ambiguous and incomplete, almost unusable for implementing a Markdown parser. The best Markdown spec we have is CommonMark. It’s not just another Markdown dialect, but really a standardized Markdown. They’ve done hard work with finding the most common behaviours among dozens of existing Markdown parsers and describing it in comprehensive specification.

[michaelmior]

Yeah, I think CommonMark compatibility seems like a good goal. Although I am still somewhat skeptical.

[kofalt]

I'd hesitate to consign their efforts to XCKD ignominy; after I gave the CommonMark spec a read, I'm convinced that their output is high quality. In my opinion they've done a great job of massaging MD's original intent and the fractal insanity of incompatibility pretty well. YMMV.

Which part of the fractal pegdown wants to represent is left as an exercise for the maintainer; the main reason I opened this ticket was an inability to get a repository's readme to simultaneously render on stash + github. I would support any movement towards CommonMark, as vendor lock-in is rarely a desirable result.