starred/markdownlint

Fork 0

mirror of https://github.com/DavidAnson/markdownlint.git synced 2026-04-26 01:36:03 +03:00

[GH-ISSUE #295] [Feature request] add `markdownlint-disable-next-line` #2100

New issue

Closed

opened 2026-03-07 20:04:33 +03:00 by kerem · 4 comments

kerem commented

2026-03-07 20:04:33 +03:00

Owner

Originally created by @Mister-Hope on GitHub (Jun 6, 2020).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/295

Currently, we can do this:

<!-- markdownlint-disable no-space-in-emphasis -->
deliberate space * in * emphasis
<!-- markdownlint-enable no-space-in-emphasis -->

But I think a support for this is better(just like eslint):

<!-- markdownlint-disable-next-line no-space-in-emphasis -->
deliberate space * in * emphasis

Why do we need it?

We can easily copy  and paste it across markdown files, while we can not do it using the first one.

E.G.:

I do not want MD040 when writing like below:

```
MyProject/
  src/
    MyActivity.java
  res/
    drawable/
      graphic.png
    layout/
      main.xml
      info.xml
    mipmap/
      icon.png
    values/
      strings.xml
```

A situation like this can be triggered several times in different pages, so I would like to diable them more conviniently.

Originally created by @Mister-Hope on GitHub (Jun 6, 2020). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/295 Currently, we can do this: ```md  deliberate space * in * emphasis  ``` But I think a support for this is better(just like eslint): ```md  deliberate space * in * emphasis ``` ## Why do we need it? We can easily copy `` and paste it across markdown files, while we can not do it using the first one. E.G.: I do not want MD040 when writing like below: ````md ``` MyProject/ src/ MyActivity.java res/ drawable/ graphic.png layout/ main.xml info.xml mipmap/ icon.png values/ strings.xml ``` ```` A situation like this can be triggered several times in different pages, so I would like to diable them more conviniently.

kerem

2026-03-07 20:04:33 +03:00

closed this issue
added the
enhancement

fixed in next
labels

kerem commented

2026-03-07 20:04:35 +03:00

Author

Owner

@Mister-Hope commented on GitHub (Oct 6, 2020):

Any progress on this issue? I really think it's a good enhancement

@Mister-Hope commented on GitHub (Oct 6, 2020): Any progress on this issue? I really think it's a good enhancement

kerem commented

2026-03-07 20:04:35 +03:00

Author

Owner

@DavidAnson commented on GitHub (Oct 6, 2020):

No progress, but probably for the next release.

@DavidAnson commented on GitHub (Oct 6, 2020): No progress, but probably for the next release.

kerem commented

2026-03-07 20:04:35 +03:00

Author

Owner

@Mister-Hope commented on GitHub (Nov 28, 2020):

I think we might need to improve it.

Some parser a new line between comment and the next line.
For example, prettier requires an empty new line between HTML comment and the next line.

1. <!-- markdownlint-disable-next-line -->
2. 
3. text text.

I think the methods should be:

if the next line is an empty line, go to the next one.
if the line only contains comments and contains -disable -enable or -disable-next-ast( May be support by other linters day after) go to the next one
keep doing 1,2 then disable in next line and then enable it in the second line.

And if users do want two or more empty line, they should write:

This is error text.

<!-- markdownlint-disable -->


<!-- markdownlint-restore-->

This is error text.

Also, in this case next-line would be misleading, something like next-ast would be better.

@Mister-Hope commented on GitHub (Nov 28, 2020): I think we might need to improve it. Some parser a new line between comment and the next line. For example, prettier requires an empty new line between HTML comment and the next line. ```md 1.  2. 3. text text. ``` I think the methods should be: 1. if the next line is an empty line, go to the next one. 2. if the line only contains comments and contains `-disable` `-enable` or `-disable-next-ast`( May be support by other linters day after) go to the next one 3. keep doing 1,2 then disable in next line and then enable it in the second line. And if users do want two or more empty line, they should write: ```md This is error text.   This is error text. ``` Also, in this case `next-line` would be misleading, something like `next-ast` would be better.

kerem commented

2026-03-07 20:04:35 +03:00

Author

Owner

@DavidAnson commented on GitHub (Nov 28, 2020):

next-line is clear, easy to understand, consistent with other tools like ESLint, and it works with CommonMark which is the specification I use for resolving ambiguities. I'd like to stay with this implementation and see how it works for people. Scenarios like what you describe can always be handled by disable/enable.

@DavidAnson commented on GitHub (Nov 28, 2020): `next-line` is clear, easy to understand, consistent with other tools like ESLint, and it works with CommonMark which is the specification I use for resolving ambiguities. I'd like to stay with this implementation and see how it works for people. Scenarios like what you describe can always be handled by `disable`/`enable`.