starred/markdownlint

Fork 0

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

[GH-ISSUE #107] MD013 "code_blocks": false does not work inside listing #89

New issue

Closed

opened 2026-03-03 01:23:38 +03:00 by kerem · 5 comments

kerem commented

2026-03-03 01:23:38 +03:00

Owner

Originally created by @chicco785 on GitHub (Mar 1, 2018).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/107

i enabled the following option:

"MD013": { 
    "code_blocks": false,
}

but when i run on the following type of code (the indentation is required to avoid numbering to restart at 1):

1. Download miniswarm:

  ```bash
  $ curl -sSL https://raw.githubusercontent.com/aelsabbahy/miniswarm/master/miniswarm \
  -o /usr/local/bin/miniswarm
  $ chmod +rx /usr/local/bin/miniswarm
  ```

1. Create a cluster of three nodes (1 master and 2 workers):

  ```bash
  $ miniswarm start 3
  ```

i get the following errors:

docs/platform/swarmcluster.md: 44: MD013/line-length Line length [Expected: 80; Actual: 91]

Originally created by @chicco785 on GitHub (Mar 1, 2018). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/107 i enabled the following option: ``` "MD013": { "code_blocks": false, } ``` but when i run on the following type of code (the indentation is required to avoid numbering to restart at 1): ```` 1. Download miniswarm: ```bash $ curl -sSL https://raw.githubusercontent.com/aelsabbahy/miniswarm/master/miniswarm \ -o /usr/local/bin/miniswarm $ chmod +rx /usr/local/bin/miniswarm ``` 1. Create a cluster of three nodes (1 master and 2 workers): ```bash $ miniswarm start 3 ``` ```` i get the following errors: `docs/platform/swarmcluster.md: 44: MD013/line-length Line length [Expected: 80; Actual: 91]`

kerem

2026-03-03 01:23:38 +03:00

closed this issue
added the
bug

fixed in next
labels

kerem commented

2026-03-03 01:23:39 +03:00

Author

Owner

@DavidAnson commented on GitHub (Mar 1, 2018):

To be proper, the code blocks should be indented three spaces so they start in the same column as the list item content (two spaces is for unordered lists). I can’t try that on my phone right now - could you let me know if it helps?

@DavidAnson commented on GitHub (Mar 1, 2018): To be proper, the code blocks should be indented three spaces so they start in the same column as the list item content (two spaces is for unordered lists). I can’t try that on my phone right now - could you let me know if it helps?

kerem commented

2026-03-03 01:23:39 +03:00

Author

Owner

@chicco785 commented on GitHub (Mar 1, 2018):

it does not change the result (btw, i am using the command line client to lint the file, I suppose it should not make any difference)

@chicco785 commented on GitHub (Mar 1, 2018): it does not change the result (btw, i am using the command line client to lint the file, I suppose it should not make any difference)

kerem commented

2026-03-03 01:23:39 +03:00

Author

Owner

@DavidAnson commented on GitHub (Mar 1, 2018):

Ok, sorry. I will look at this when I finish the current feature.

@DavidAnson commented on GitHub (Mar 1, 2018): Ok, sorry. I will look at this when I finish the current feature.

kerem commented

2026-03-03 01:23:39 +03:00

Author

Owner

@snordmann commented on GitHub (Oct 23, 2018):

The change you did was to allow zero to three spaces in front of code blocks. This change doesn't work on nested lists:

- Test1
  - Test2
    ```bash
    code goes over 80 chars here
    ```

Is there a reason to exclude nested lists and not allow all spaces before code blocks?

I propose a change from:

var match = /^[ ]{0,3}(`{3,}|~{3,})/.exec(line);

to:

var match = /^[ ]*(`{3,}|~{3,})/.exec(line);

@snordmann commented on GitHub (Oct 23, 2018): The change you did was to allow zero to three spaces in front of code blocks. This change doesn't work on nested lists: ```text - Test1 - Test2 ```bash code goes over 80 chars here ``` ``` Is there a reason to exclude nested lists and not allow all spaces before code blocks? --- I propose a change from: ```javascript lib/shared.js:144 var match = /^[ ]{0,3}(`{3,}|~{3,})/.exec(line); ``` to: ```javascript lib/shared.js:144 var match = /^[ ]*(`{3,}|~{3,})/.exec(line); ```

kerem commented

2026-03-03 01:23:39 +03:00

Author

Owner

@DavidAnson commented on GitHub (Oct 23, 2018):

I think I read the specification too literally: https://spec.commonmark.org/0.28/#fenced-code-blocks

It talks about indents, but isn’t explicit (in this section) whether the indent is relative to the start of the line (as I implemented) or the current indent level (as in a list like you show). And none of the examples there are affected by this.

Your proposal seems not to be entirely right, either, because 4 spaces creates an indented code block (example 103) but isn’t handled differently.

Could you please create a new issue? It may be tricky to handle this with a RegExp, but I agree the current behavior should be improved.

Thank you!

@DavidAnson commented on GitHub (Oct 23, 2018): I think I read the specification too literally: https://spec.commonmark.org/0.28/#fenced-code-blocks It talks about indents, but isn’t explicit (in this section) whether the indent is relative to the start of the line (as I implemented) or the current indent level (as in a list like you show). And none of the examples there are affected by this. Your proposal seems not to be entirely right, either, because 4 spaces creates an indented code block (example 103) but isn’t handled differently. Could you please create a new issue? It may be tricky to handle this with a RegExp, but I agree the current behavior should be improved. Thank you!

kerem referenced this issue

2026-03-03 01:30:19 +03:00

[PR #176] [CLOSED] Adding new rule for enforcing new lines at the end of file, fixes #89 #821

kerem referenced this issue

2026-03-07 20:02:48 +03:00

[GH-ISSUE #89] Newline before EOF #1922

kerem referenced this issue

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

[PR #176] [CLOSED] Adding new rule for enforcing new lines at the end of file, fixes #89 #2668