MD049, MD050 conflicts with functional differences between underscores and asterisks
EthanRutherford opened this issue · comments
In the commonmark spec, there are clear differences (and therefore different case by case tradeoffs to be made) between the parsing rules for asterisk emphasis and underscore emphasis.
https://spec.commonmark.org/0.30/#emphasis-and-strong-emphasis
The difference comes mostly down to intra-word emphasis parsing. some_pascal_case_string has internal underscores that are clearly not intended to cause emphasis, while anticlockwise uses internal asterisks to emphasize a particular part of a word.
There's much more context in the link above, but in short there are functional differences between the two, picking one or the other is not a purely aesthetic choice, and restricting to only one or the other will prevent certain use cases.
Agree, although I think the vast majority of the use of emphasis in Markdown does not involve interword scenarios. The default for both of these rules is to enforce consistency with either approach, so people with preferences or relevant scenarios should similarly not be affected. And of course anyone who needs to mix things can disable the rules at the line/document/project level. Are you suggesting these rules should be deleted or just calling out the specifics here?
Just pointing it out. The descriptions for these rules doesn't make any mention of the distinction, so it was unclear if this was an oversight or not.
It may be useful for the rule to be able to detect cases where the other delimiter is necessary, and allow the use in such conditions.
The code already detects the underscore intraword scenario called out in the specification: https://github.com/DavidAnson/markdownlint/blob/main/lib/md049-md050.js
Do you have any examples of mis-reporting by these rules?
That's good to know, thanks. I was hesitant to enable the rule, as the description seemed to imply that there was no consideration. I'm also admittedly likely more aware of the distinction than the average user, having implemented a spec compliant parser at a former job. Considering that, I don't know if there's really anything actionable. Feel free to close this