on 31 Dec, 2016 06:58 PM
Hi Fletcher, file is attached
I managed to get yyparse debugging enabled and have a13G dump of the output
of yyparse when I'm going to crawl through if something doesn't pop out to
you. I'm using the latest version, I pulled it from github and rebuilt from
on 01 Jan, 2017 01:09 AM
That it isn't valid HTML is certainly possible, it is the penultimate step
before my CMS system considers is ready to publish. Once the markdown in
the file has been process it is the contents value of another template
which puts things around it. Looking at the enclosing template though it
shouldn't have unmatched div's. I'll check that in my CMS code. I also
spent a lot of time bisecting the file to figure out if there was a line
that hung the parser (and eventually discovered that bisecting it anywhere
and both "halves" of the result would process.
on 01 Jan, 2017 06:31 AM
Thanks for the clue! I went back into my site generation code and found the
template that was missing the closing div. I fixed that and the site
published as expected. (and the index page went back to being legal html at
that point). So it seems like the issue was too many open <div> tags. That
said, I wonder if multimarkdown could catch that and error out rather than
fletcher on 01 Jan, 2017 12:22 PM
The problem is that the way PEGs work is that it keeps trying to find matched pairs of opening and closing tags that would represent HTML blocks. It "knows" that each opener should have a closer but struggles to figure out how to pair them up when the numbers are wrong. It has to check the entire rest of the document because it's possible there are a bunch of closers all together at the end, but it never finds them. And it has to do that every time it finds a new opener. And you have a lot of openers in your document.
I'm working on MultiMarkdown 6, which works in an entirely different way and should be ok on this. But it's not ready yet.