[GH-ISSUE #1052] MD049, MD050 conflicts with functional differences between underscores and asterisks #2451

New issue

Closed

opened 2026-03-07 20:07:52 +03:00 by kerem · 5 comments

kerem commented

2026-03-07 20:07:52 +03:00

Owner

Originally created by @EthanRutherford on GitHub (Nov 29, 2023).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1052

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.

Originally created by @EthanRutherford on GitHub (Nov 29, 2023). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1052 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 *anti*clockwise 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.

kerem

2026-03-07 20:07:52 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-07 20:07:53 +03:00

Author

Owner

@DavidAnson commented on GitHub (Nov 29, 2023):

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?

@DavidAnson commented on GitHub (Nov 29, 2023): 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?

kerem commented

2026-03-07 20:07:54 +03:00

Author

Owner

@EthanRutherford commented on GitHub (Nov 29, 2023):

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.

@EthanRutherford commented on GitHub (Nov 29, 2023): 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.

kerem commented

2026-03-07 20:07:54 +03:00

Author

Owner

@EthanRutherford commented on GitHub (Nov 29, 2023):

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.

@EthanRutherford commented on GitHub (Nov 29, 2023): 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.

kerem commented

2026-03-07 20:07:54 +03:00

Author

Owner

@DavidAnson commented on GitHub (Nov 29, 2023):

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?

@DavidAnson commented on GitHub (Nov 29, 2023): 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?

kerem commented

2026-03-07 20:07:54 +03:00

Author

Owner

@EthanRutherford commented on GitHub (Nov 29, 2023):

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

@EthanRutherford commented on GitHub (Nov 29, 2023): 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