-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect behaviour for mixed list types? #437
Comments
First of all: Perhaps the most serious problem of Markdown is, that it never really was standardized. The only common denominator of all Markdown parsers is a descriptive document from John Gruber and his original However, in the recent past some people started the CommonMark project to resolve these uncertainties. The project is very promising, it comes with both a pretty complete specification of Markdown and a (very slow) reference parser. Many Markdown parser projects have already declared that they will try to improve compliance to the CommonMark specs and Parsedown is no exception here. Anyway, to cut a long story short, if there's a problem or open question about how Parsedown behaves or should behave, the CommonMark specs should be consulted. In this case the expected result you're describing matches the specs (unfortunately there's no matching example in the specs, it results from the "of-the-same-type" rule). You can also have a look at the CommonMark reference parser. Therefore, yes, this should be considered as a bug. |
Okay, since it's a bug I'll take a look at a fix ;-) It doesn't look too bad upon first glance, so I'll take a stab at it later on when I get a chance to test out some changes :) |
Great, as long as the solution doesn't conflict with CommonMark and doesn't add too much complexity, I'm in favor :) |
Getting the i.e.
You'll notice the above isn't quite correct – a problem I'm having is checking whether the list nesting is the same as the list that has currently been started. I figured that Any ideas on another piece of data I could use to determine the depth of the current line relative to the block? Or should the line indent vs. block indent be enough? |
I'm super busy these days working on @careteditor. I could give it some thought later this month. |
@aidantwoods: See http://spec.commonmark.org/0.26/#example-255
Thus comparing the block's and line's indent is completely fine to determine whether the list is continued or not, and whether a sublist is started or not. fyi: You can use |
@PhrozenByte I'm creating a pull request, just so you can see the changes I've made to start this off – obviously it's not fit for merging yet. |
#439 is merged, closing |
For the following data (I'll prepend this at the beginning of each section to avoid scrolling to compare with output):
This data produces different results for each parser I've tested in, so I'm not clear on what the standard actually should be. That said my expectation would have been that, the parser would honour the solution closest the the user input.
This isn't a bug-report per-say, because I'm not entirely sure that it is a bug, but more a query to see if Parsedown is acting as expected?
The aforementioned expected result is as follows
Expected
Source
Result
#### HTML
However, these are the results of tested parsers:
Parsedown
Source
Result
#### HTML
Markdown PHP 1.3
Source
Result
#### HTML
GitHub
Source
Result
Obviously this one is horrendously wrong, still, it's a comparison point:
HTML
The text was updated successfully, but these errors were encountered: