starred/markdownlint

Fork 0

mirror of https://github.com/DavidAnson/markdownlint.git synced 2026-04-25 09:16:02 +03:00

[GH-ISSUE #190] Trailing spaces not allowed in indented code blocks #165

New issue

Closed

opened 2026-03-03 01:24:18 +03:00 by kerem · 4 comments

kerem commented

2026-03-03 01:24:18 +03:00

Owner

Originally created by @wouter-admiraal-sonarsource on GitHub (May 23, 2019).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/190

Hi,

First of all, thanks for this awesome tool 👍 !

I ran into an issue when using indented code blocks. Consider this Markdown snippet:

# example.md

Code snippet example:

    package org.example;
    
    public class Lorem {
    
      Lorem() {
      
      }
      
      public void tryMe() {
        /* ... */
      }
    
    }

End of code snippet.

This is using the original, "standard" Markdown (which doesn't have fenced code blocks). In this code snippet, I have several blank lines to improve readability. This means, the snippet renders like so:

package org.example;

public class Lorem {

  Lorem() {
  
  }
  
  public void tryMe() {
    /* ... */
  }

}

If the empty lines were to be trimmed, it would render something like this:

package org.example;

public class Lorem {

  Lorem() {

  public void tryMe() {
    /* ... */
  }

So, the empty lines need to be indented like the rest.

However, rule MD009 flags this is as incorrect, and fails with:

example.md: 5: MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 4]
example.md: 7: MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 4]
example.md: 9: MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 6]
example.md: 11: MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 6]
...

I suggest this rule be deactivated whenever we're inside a code block. Lines containing nothing but white space probably have a special meaning when in context of code. I would imagine this could be done for both indented and fenced code blocks, but I could be wrong.

Note: I actually started forking and was preparing a PR, but then I saw that you prefer an issue opened first :-). So, this is the issue. But JIC, here is a commit with a proposed fix, along with an update test. The test -- correctly -- fails if the fix is not implemented.

Originally created by @wouter-admiraal-sonarsource on GitHub (May 23, 2019). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/190 Hi, First of all, thanks for this awesome tool 👍 ! I ran into an issue when using indented code blocks. Consider this Markdown snippet: ```md # example.md Code snippet example: package org.example; public class Lorem { Lorem() { } public void tryMe() { /* ... */ } } End of code snippet. ``` This is using the original, "standard" Markdown (which doesn't have fenced code blocks). In this code snippet, I have several blank lines to improve readability. This means, the snippet renders like so: ``` package org.example; public class Lorem { Lorem() { } public void tryMe() { /* ... */ } } ``` If the empty lines were to be trimmed, it would render something like this: ``` package org.example; ``` ``` public class Lorem { ``` ``` Lorem() { ``` ``` } ``` ``` public void tryMe() { /* ... */ } ``` ``` } ``` So, the empty lines need to be indented like the rest. However, rule MD009 flags this is as incorrect, and fails with: ```text example.md: 5: MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 4] example.md: 7: MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 4] example.md: 9: MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 6] example.md: 11: MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 6] ... ``` I suggest this rule be deactivated whenever we're inside a code block. Lines containing nothing but white space probably have a special meaning when in context of code. I would imagine this could be done for both indented and fenced code blocks, but I could be wrong. _Note: I actually started forking and was preparing a PR, but then I saw that you prefer an issue opened first :-). So, this is the issue. But JIC, [here is a commit](https://github.com/wouter-admiraal-sonarsource/markdownlint/commit/336267de51a2f3311b7cbb2213f7b0d3fdd8510c) with a proposed fix, along with an update test. The test -- correctly -- fails if the fix is not implemented._

kerem

2026-03-03 01:24:18 +03:00

closed this issue
added the
enhancement

fixed in next
labels

kerem commented

2026-03-03 01:24:20 +03:00

Author

Owner

@DavidAnson commented on GitHub (May 23, 2019):

Thank you for the very detailed issue!

I agree with the change you propose for indented code blocks. However, I don’t see a need to change the behavior for fenced blocks. (Convince me with an example?)

Could you please create a PR with your commit? I propose the following tweaks:

Change behavior to only apply for indented code blocks
Move the condition of the new if statement into the existing conditional two lines below (should reduce code churn)
Change the text of the test case to remove “newline” because it’s about trailing spaces, not CR/LF
Send the PR against next branch (I need to update CONTRIBUTING, sorry)

@DavidAnson commented on GitHub (May 23, 2019): Thank you for the very detailed issue! I agree with the change you propose for indented code blocks. However, I don’t see a need to change the behavior for fenced blocks. (Convince me with an example?) Could you please create a PR with your commit? I propose the following tweaks: - Change behavior to only apply for indented code blocks - Move the condition of the new `if` statement into the existing conditional two lines below (should reduce code churn) - Change the text of the test case to remove “newline” because it’s about trailing spaces, not CR/LF - Send the PR against `next` branch (I need to update CONTRIBUTING, sorry)

kerem commented

2026-03-03 01:24:20 +03:00

Author

Owner

@wouter-admiraal-sonarsource commented on GitHub (May 24, 2019):

Thanks for the reply. I'm not sure for the fenced blocks. I was more thinking: "it won't hurt".

Looking through the code, I don't see any way to see in what kind of code block the current line is. This means I'd introduce some new state when looping over the lines. Is that correct?

PR #191 created.

@wouter-admiraal-sonarsource commented on GitHub (May 24, 2019): Thanks for the reply. I'm not sure for the fenced blocks. I was more thinking: "it won't hurt". Looking through the code, I don't see any way to see in what kind of code block the current line is. This means I'd introduce some new state when looping over the lines. Is that correct? PR #191 created.

kerem commented

2026-03-03 01:24:20 +03:00

Author

Owner

@DavidAnson commented on GitHub (May 24, 2019):

It should be easy. I’ll add a note to the PR. Thank you!

@DavidAnson commented on GitHub (May 24, 2019): It should be easy. I’ll add a note to the PR. Thank you!

kerem commented

2026-03-03 01:24:20 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jun 9, 2019):