starred/markdownlint

Fork 0

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

[GH-ISSUE #524] Feature Request: markdownlint-disable-line #427

New issue

Closed

opened 2026-03-03 01:26:49 +03:00 by kerem · 6 comments

kerem commented

2026-03-03 01:26:49 +03:00

Owner

Originally created by @Zamiell on GitHub (May 9, 2022).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/524

Hello, and thanks for the excellent linter!

Currently, markdownlint has the disable-next-line directive, which is quite a handy feature!

For example, the README.md file gives the following example:

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

Unfortunately, this not the greatest example, because if you have Prettier installed (which many projects do nowadays), as soon as you hit Ctrl + s in VSCode to save the file, Prettier will automatically reformat it to the following:

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

deliberate space * in * emphasis

And now the comment will no longer apply.

This happened to me earlier today. Being familiar with ESLint, I intuitively knew how to fix the problem, so I tried this:

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

But unfortunately, that doesn't work, because surprisingly, markdownlint only supports disable-next-line and not disable-line.

Can this please be added?

Originally created by @Zamiell on GitHub (May 9, 2022). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/524 Hello, and thanks for the excellent linter! Currently, markdownlint has the `disable-next-line` directive, which is quite a handy feature! For example, the `README.md` file gives the following example: ```md  deliberate space * in * emphasis ``` Unfortunately, this not the greatest example, because if you have Prettier installed (which many projects do nowadays), as soon as you hit `Ctrl + s` in VSCode to save the file, Prettier will automatically reformat it to the following: ```md  deliberate space * in * emphasis ``` And now the comment will no longer apply. This happened to me earlier today. Being familiar with [ESLint](https://eslint.org/), I intuitively knew how to fix the problem, so I tried this: ```md deliberate space * in * emphasis  ``` But unfortunately, that doesn't work, because surprisingly, markdownlint only supports `disable-next-line` and not `disable-line`. Can this please be added?

kerem

2026-03-03 01:26:49 +03:00

closed this issue
added the
enhancement

fixed in next
labels

kerem commented

2026-03-03 01:26:50 +03:00

Author

Owner

@DavidAnson commented on GitHub (May 9, 2022):

You can do this with disable/restore as shown in the documentation: https://github.com/DavidAnson/markdownlint#configuration

@DavidAnson commented on GitHub (May 9, 2022): You can do this with disable/restore as shown in the documentation: https://github.com/DavidAnson/markdownlint#configuration

kerem commented

2026-03-03 01:26:50 +03:00

Author

Owner

@Zamiell commented on GitHub (May 9, 2022):

@DavidAnson Thanks for the quick response.
I see in the docs that it is possible to do disable/restore, but this is pretty cumbersome.
It also is not very DRY - programmers will have to duplicate the code on multiple lines.
It would be better UX and less maintenance for end-users if this linter could also have the disable-line feature, which would allow programmers to specify the directive and associated rule exactly one time.

Other popular linters like ESLint and CSpell have this functionality, so I think it is reasonable for markdownlint to have it too.

@Zamiell commented on GitHub (May 9, 2022): @DavidAnson Thanks for the quick response. I see in the docs that it is possible to do disable/restore, but this is pretty cumbersome. It also is not very DRY - programmers will have to duplicate the code on multiple lines. It would be better UX and less maintenance for end-users if this linter could also have the `disable-line` feature, which would allow programmers to specify the directive and associated rule exactly one time. Other popular linters like [ESLint](https://eslint.org/) and [CSpell](https://cspell.org/) have this functionality, so I think it is reasonable for `markdownlint` to have it too.

kerem commented

2026-03-03 01:26:50 +03:00

Author

Owner

@DavidAnson commented on GitHub (May 9, 2022):

In my opinion, "next line" is better than "line" because it is clear, it doesn't interfere with the content, and it doesn't risk creating too-long lines. The problem is that Prettier breaks that and needs to be worked around. It would be nice if Prettier were more respectful here, but I can look into adding "line" as an alternative.

@DavidAnson commented on GitHub (May 9, 2022): In my opinion, "next line" is better than "line" because it is clear, it doesn't interfere with the content, and it doesn't risk creating too-long lines. The problem is that Prettier breaks that and needs to be worked around. It would be nice if Prettier were more respectful here, but I can look into adding "line" as an alternative.

kerem commented

2026-03-03 01:26:50 +03:00

Author

Owner

@Zamiell commented on GitHub (May 9, 2022):

In my opinion, "next line" is better than "line" because it is clear, it doesn't interfere with the content, and it doesn't risk creating too-long lines.

100% agree!

The problem is that Prettier breaks that and needs to be worked around. It would be nice if Prettier were more respectful here

Agreed! But I don't think it would be practical for Prettier to hardcode an array with the names of all of the popular linters out there, and then treat comments with those keywords with special behavior. So it doesn't seem like a problem that Prettier can fix upstream either.

I can look into adding "line" as an alternative.

Thank you!

@Zamiell commented on GitHub (May 9, 2022): > In my opinion, "next line" is better than "line" because it is clear, it doesn't interfere with the content, and it doesn't risk creating too-long lines. 100% agree! > The problem is that Prettier breaks that and needs to be worked around. It would be nice if Prettier were more respectful here Agreed! But I don't think it would be practical for Prettier to hardcode an array with the names of all of the popular linters out there, and then treat comments with those keywords with special behavior. So it doesn't seem like a problem that Prettier can fix upstream either. > I can look into adding "line" as an alternative. Thank you!

kerem commented

2026-03-03 01:26:50 +03:00

Author

Owner

@DavidAnson commented on GitHub (May 9, 2022):

I know of just one other Markdown linting tool in the Node ecosystem. I think they could handle it if they wanted to. :)

@DavidAnson commented on GitHub (May 9, 2022): I know of just one other Markdown linting tool in the Node ecosystem. I think they could handle it if they wanted to. :)

kerem commented

2026-03-03 01:26:50 +03:00

Author

Owner

@Zamiell commented on GitHub (May 9, 2022):

Well, what about CSpell? Surely, many people need to spell check their markdown documents. If you're not familiar with it, it has syntax like this:

It is common to misspell the word absence as "absense". <!-- cspell:disable-line absense -->

So that would have to be added as well. And what if some other extension for spell checking started to get more popular than CSpell? Or some other markdown linter got more popular than markdownlint? Should that be added too? I wouldn't be surprised if there were other tools that lint markdown that I'm not personally aware of, so maybe the list could get quite long.

It seems pretty weird for Prettier to be in the business of hard-coding popular tools, as that would be a maintenance burden, especially for a hypothetical niche feature like this.

@Zamiell commented on GitHub (May 9, 2022): Well, what about CSpell? Surely, many people need to spell check their markdown documents. If you're not familiar with it, it has syntax like this: ```md It is common to misspell the word absence as "absense".  ``` So that would have to be added as well. And what if some other extension for spell checking started to get more popular than CSpell? Or some other markdown linter got more popular than markdownlint? Should that be added too? I wouldn't be surprised if there were other tools that lint markdown that I'm not personally aware of, so maybe the list could get quite long. It seems pretty weird for Prettier to be in the business of hard-coding popular tools, as that would be a maintenance burden, especially for a hypothetical niche feature like this.

kerem referenced this issue

2026-03-07 20:05:31 +03:00

[GH-ISSUE #427] MD037 false positives with * in a <code> #2205