mirror of
https://github.com/DavidAnson/markdownlint.git
synced 2026-04-26 09:46:01 +03:00
[GH-ISSUE #810] Support underlining style via _ (underscores) and italics via * (asterisks) simultaneously #2386
Labels
No labels
bug
enhancement
enhancement
enhancement
fixed in next
fixed in next
fixed in next
new rule
new rule
new rule
pull-request
question
refactoring
refactoring
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/markdownlint#2386
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @redactedscribe on GitHub (May 8, 2023).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/810
Regarding MD049: The only options are
asterisk/consistent/underscore. If we could have amixedoroffoption, we could use*for emphasis (italicisation) and_for underlining without markdownlint complaining that we have inconsistent emphasis styling in play. This however would give up the checks we have for emphasising which isn't ideal.Maybe some specific support could be given to underlining so that markdownlint could ensure we're using asterisks for emphasis and underscores for underlining? I don't know how common support for underlining in Markdown parsers is, but the Markdown Extended VS Code extension enables support for it (via something called markdown-it I think) and it would be cool if markdownlint could support underlining too.
Thanks.
markdownlint 0.50.0
@nschonni commented on GitHub (May 8, 2023):
"Underlining" isn't part of CommonMark spec https://spec.commonmark.org/0.30/. There asterisks and underscore both produce
<em>elements only in compliant parsers@DavidAnson commented on GitHub (May 8, 2023):
Agreed. This behavior is not per specification (the plug-in agrees: https://www.npmjs.com/package/markdown-it-underline) and it would be confusing to try to support it for this one isolated case.
@redactedscribe commented on GitHub (May 8, 2023):
I'm not educated enough on the details to argue otherwise so I'll have to agree. I thought it may be common among other parsers etc. Feel free to close if this is clear-cut.
@redactedscribe commented on GitHub (May 9, 2023):
Another thought: Since underlining via underscore would just render as emphasised text in parsers which don't handle underscores vs asterisks differently, with an
offoption for MD049, we could at least use both styles in VS Code via Markdown Extended without markdownlint complaining, even if the linter won't support underlining specifically.@DavidAnson commented on GitHub (May 9, 2023):
An "off" setting would seem to be the same as disabling the rule. All rules can already be disabled via configuration. (See the README)