Fix #466

[aidantwoods]

Beginnings of a potential fix to #466 – provided this doesn't break anything unexpectedly

[aidantwoods]

Seems that the Commonmark reference parser is opting to have block structures that aren't properly indented interrupt the previous block structure (which seems sensible). Rather than to embed the new block structure within the previous (which is what Parsedown is currently doing).

These changes should allow the block* methods to set an indentation level for the block, but if they don't, then the indentation is set to be the current line indent (I think this is sensible?)

Have had to change the way list indentation is calculated (so that initial whitespace and marker width is taken into account, I don't think its quite per spec yet, so the failed tests are expected until I figure out the best way to do that 😉

The added check:

if (isset($CurrentBlock['indent']) and isset($NewBlock) and $NewBlock['indent'] < $CurrentBlock['indent'])
{
    $CurrentBlock['interrupted'] = true;
}

does fix the #466

(will have to go through the test results now to double check nothing unexpected has broken)

[aidantwoods]

Okay, so looks like this no longer breaks anything in the Parsedown tests.

Not fit for merge yet though, still need to make sure list indents are done correctly.

What I've done so far is make sure that an initial list won't have an indentation of zero (which it would do previously) so we can differentiate between a block started within the list, and one started after but alongside the list (lesser indentation level than the content of the list, and should thus interrupt the list).

But would still like to make sure the indentation level I'm assigning is moving to something more inline with the commonmark spec.

[PhrozenByte]

Side note @erusev: Merging #423 and #440 would make testing changes against the CommonMark specs significantly easier... 😉

Looks good to me @aidantwoods. Have you checked your changes against the CommonMark tests yet? There might be some related tests that allow us to kill two birds with one stone. 😃

[aidantwoods]

@PhrozenByte

It fixes some, and breaks some (hard to know if previously passed tests were intentional)

There are a few to do with references (some of which are apparently solved by undoing that last commit that prevents the definition log being written to on a block test o.0)

This one inserts an extra paragraph if the list content falls behind the marker

I think the most serious breakages are #85

which inserts an extra line into code

I solved that by specifying the correct indent in the blockCode method.

And the ones to do with empty list item parsing (no whitespace in item, just the delimiter)

Any ideas on what to do about these?

[aidantwoods]

Oh, and I know you're not really meant to do this in comments anymore, but +1 on merging #423 and #440! 😉

Had to go and download the working CommonMark tests from @PhrozenByte's fork, and then add them in manually to different snapshots of Parsedown to compare the test results

[aidantwoods]

Oh, and obviously there are a few nice list tests that no longer fail

[aidantwoods]

One of the things I'm noticing, is that block interrupts are going to have to be decoupled from being caused by a blank line, e.g. on this fall-through condition which is implied by an interrupt

parsedown/Parsedown.php

Line 586 in 0172d77

$Block['li']['text'] []= '';

[erusev]

I'll need some time to review this.