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
Emphasis intersection bug? #475
Comments
Apologies, correction: it appears that rule 15 does not apply because the given example does not overlap in the way specified. In which case rule 13 should be applied as far as I can tell:
In any case, <p><strong>strong* still strong</strong></p> is prefered by this rule too. |
Most implementations seems to agree with this http://johnmacfarlane.net/babelmark2/?text=**strong*+still+strong** (though they don't appear on the page for me, can get some results by going through the network responses): |
Although I agree that the interpretation of this case is unexpected, I've come to appreciate that it's not possible to give a spec for emphasis that gives "intuitive" results in every case. The best we can do is to minimize the unintuitive cases, and the principles in the spec (now fairly complex) have been motivated by consideration of a large number of cases. Maybe there's a way to modify the principles to get the "intuitive" result in your case without messing delivering other unintuitive results elsewhere, and without making it impossible to parse emphasis efficiently. We're very open to suggestions there. But otherwise we may have to accept that this is a case where you need to backslash-escape the asterisk. Not a big deal. |
So I'll close this, but feel free to re-open if you have a specific proposal. |
My concern, I suppose, isn't that it's an unintuitive result, rather that the result given by the reference parser contradicts the spec as far as I can tell? I don't much mind which result we pick (I would perhaps lean toward the one that I say is "expected" but it doesn't matter so much), rather I think it is important that the result is defined :) (I'm painfully aware of how complex emphasis parsing is already) |
(Btw apparently I can't re-open the issue if you closed it o.0 – behaviour is news to me) |
Sorry, in skimming this I saw the point about rule 15 not applying, but missed the point about rule 13 applying.... I'll re-open. |
Rule 13 is a bit vague; perhaps if we try to be more precise about what is meant by "minimize nesting", we can bring the spec in conformity with the way the reference parsers treat this case. E.g. maybe we could just say:
|
I think if you remove the phrase "minimise nesting" then this case becomes undefined. Since the difference between what I've called the expected result and the reference parser's isn't picking Just to be clear here, which result are we aiming for? :) If we're aiming for the result that the reference parser currently gives ( If on the other hand we are aiming for the "expected result" ( |
Given the following markdown:
The online reference parser gives this output:
However, using rule 15 (just below http://spec.commonmark.org/0.27/#can-open-emphasis)
I think the output should be this
Instead, the parser is behaving more like it would when faced with rule 16
Even though these emphasis and strong emphasis spans do not have the same closing delimiter (so this rule should not apply).
Note that I am assuming that the phrase same closing delimiter (which is not formally defined) is referring to a delimiter run as categorised by its starting position in the string (this holds for the example given).
The text was updated successfully, but these errors were encountered: