mirror of
https://github.com/DavidAnson/markdownlint.git
synced 2026-04-26 09:46:01 +03:00
[GH-ISSUE #1665] MD038: False positives for no-space-in-code #730
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#730
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 @asponring on GitHub (Jul 9, 2025).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/1665
I recently tried going from markdownlint-cli 0.33 to 0.45, thereby going from markdownlint 0.27 to 0.38. I have always had MD038 enabled, but with the upgrade suddenly I got a number of false positives. I compiled the examples into a single test.md file and ran markdownlint on it to show the error.
The text:
The linter tells me this:
None of these failures reflect actual whitespace immediately within the backticks, which is what the rule is supposed to catch. From my experimentation, removing a couple surrounding lines seems to help, but I really don't know what's happening behind the scenes.
Thank you for your help and for making this great tool!
@DavidAnson commented on GitHub (Jul 9, 2025):
You can see from the way the table renders that it's not being parsed how you expect. The pipe character takes precedence over backtick, so there are some weird code spans in your example and the issues are probably valid. If you want a pipe character inside a table cell, it should be escaped per the specification: https://github.github.com/gfm/#example-200
Escaping the pipe character in the
true|falsecell cleans up the table, but the use of unescorted dollar in the bottom paragraph looks like a math expression, so escaping the dollar character of$PATHis also necessary.After those two tweaks, your example renders reasonably and with no errors.
Playground: https://dlaa.me/markdownlint/#%25m%23%20Issue%201665%0A%0A%7C%20Property%20%7C%20Description%20%7C%20Type%20%7C%20Default%20%7C%20Version%20%7C%0A%7C%20---%20%7C%20---%20%7C%20---%20%7C%20---%20%7C%20---%20%7C%0A%7C%20autoSize%20%7C%20Height%20autosize%20feature%2C%20can%20be%20set%20to%20%60true%7Cfalse%60%20or%20an%20object%20%60%7B%20minRows%3A%202%2C%20maxRows%3A%206%20%7D%60.%20%60autosize%60%20is%20deprecated%20after%20%603.24.0%60%2C%20please%20use%20%60autoSize%60.%20%7C%20boolean%5C%7Cobject%20%7C%20false%20%7C%203.24.0%20%7C%0A%0AThe%20developer.profile%20script%20adds%20this%20directory%20to%20the%20%24PATH.%0A(It's%20important%20that%20this%20directory%20takes%0Adirectories%20for%20binaries%2C%20such%20as%20%60%24HOME%2Fbin%60%2C%20so%20that%20the%20versioned%20tools%20are%0Aconsistently%20used.)%20The%20%60checkenv%60%20tool%20verifies.%0A
@asponring commented on GitHub (Jul 9, 2025):
Thanks @DavidAnson! Agreed that table doesn't look right so that clears it up.
Regarding the interpretation of the unescaped dollar sign, it seems unfortunate that we'd have to escape it or enclose it in backticks lest it be interpreted as a math expression. I wasn't aware that was standard markdown.
This blog post makes it seem like that interpretation of the dollar sign only comes with a Math extension: https://geoffgraham.me/how-to-format-money-in-markdown/
Is there a reason that markdownlint does this by default?
@DavidAnson commented on GitHub (Jul 9, 2025):
Enough people expect math expressions to work in Markdown that the linter includes that extension by default. It's not usually an issue and escaping the dollar character is easy enough that it hasn't been a problem.
@asponring commented on GitHub (Jul 15, 2025):
Thanks for the answer! I'll go ahead and close this.