[GH-ISSUE #1665] MD038: False positives for no-space-in-code #730

Closed
opened 2026-03-03 01:29:25 +03:00 by kerem · 4 comments
Owner

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:

| Property | Description | Type | Default | Version |
| --- | --- | --- | --- | --- |
| autoSize | Height autosize feature, can be set to `true|false` or an object `{ minRows: 2, maxRows: 6 }`. `autosize` is deprecated after `3.24.0`, please use `autoSize`. | boolean\|object | false | 3.24.0 |

The developer.profile script adds this directory to the $PATH.
(It's important that this directory takes
directories for binaries, such as `$HOME/bin`, so that the versioned tools are
consistently used.) The `checkenv` tool verifies.

The linter tells me this:

test.md:3:160 MD038/no-space-in-code Spaces inside code span elements [Context: "`, please use `"]
test.md:3:108 MD038/no-space-in-code Spaces inside code span elements [Context: "`. `"]
test.md:8:24 MD038/no-space-in-code Spaces inside code span elements [Context: "... are
consistently used.) The `"]

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!

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: ``` | Property | Description | Type | Default | Version | | --- | --- | --- | --- | --- | | autoSize | Height autosize feature, can be set to `true|false` or an object `{ minRows: 2, maxRows: 6 }`. `autosize` is deprecated after `3.24.0`, please use `autoSize`. | boolean\|object | false | 3.24.0 | The developer.profile script adds this directory to the $PATH. (It's important that this directory takes directories for binaries, such as `$HOME/bin`, so that the versioned tools are consistently used.) The `checkenv` tool verifies. ``` The linter tells me this: ``` test.md:3:160 MD038/no-space-in-code Spaces inside code span elements [Context: "`, please use `"] test.md:3:108 MD038/no-space-in-code Spaces inside code span elements [Context: "`. `"] test.md:8:24 MD038/no-space-in-code Spaces inside code span elements [Context: "... are consistently used.) The `"] ``` 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!
kerem 2026-03-03 01:29:25 +03:00
  • closed this issue
  • added the
    question
    label
Author
Owner

@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|false cell 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 $PATH is 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

<!-- gh-comment-id:3053566098 --> @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|false` cell 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 `$PATH` is 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>
Author
Owner

@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?

<!-- gh-comment-id:3053670877 --> @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?
Author
Owner

@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.

<!-- gh-comment-id:3053744036 --> @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.
Author
Owner

@asponring commented on GitHub (Jul 15, 2025):

Thanks for the answer! I'll go ahead and close this.

<!-- gh-comment-id:3074400299 --> @asponring commented on GitHub (Jul 15, 2025): Thanks for the answer! I'll go ahead and close this.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/markdownlint#730
No description provided.