[GH-ISSUE #194] markdownlint-enable after markdownlint-disable no longer respects rules set in config #2016

New issue

Closed

opened 2026-03-07 20:03:43 +03:00 by kerem · 3 comments

kerem commented

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

Owner

Originally created by @boneskull on GitHub (Jun 6, 2019).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/194

I have a file containing some automatically-generated markdown.

I would like markdownlint to ignore the auto-generated content, so I wrap the section with this:

<!-- markdownlint-disable -->
<!-- auto-generated content here -->
<!-- markdownlint-enable -->

In my .markdownlint.json, I have this rule:

{
  "line-length": false
}

However, markdownlint complains that a line following (not immediately after) the  exceeds the expected line length of 80.

This error is only emitted if I use the disable/enable wrapper.

Essentially, this seems to imply that  does not re-read the configuration, and instead reverts to the default. This problem can be trivially reproduced with this file:

<!-- markdownlint-disable -->
<!-- markdownlint-enable -->

The quick brown fox jumped over the lazy dog. The quick brown fox jumped over the lazy dog. The quick brown fox jumped over the lazy dog.

Originally created by @boneskull on GitHub (Jun 6, 2019). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/194 I have a file containing some automatically-generated markdown. I would like markdownlint to ignore the auto-generated content, so I wrap the section with this: ```md    ``` In my `.markdownlint.json`, I have this rule: ```json { "line-length": false } ``` However, markdownlint complains that a line following (not immediately after) the `` exceeds the expected line length of 80. This error is *only emitted* if I use the disable/enable wrapper. Essentially, this seems to imply that `` does not re-read the configuration, and instead reverts to the default. This problem can be trivially reproduced with this file: ```md   The quick brown fox jumped over the lazy dog. The quick brown fox jumped over the lazy dog. The quick brown fox jumped over the lazy dog. ```

kerem

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

closed this issue
added the
enhancement

fixed in next
labels

kerem commented

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

Author

Owner

@boneskull commented on GitHub (Jun 6, 2019):

I have a feeling this is user error, but that's unclear from the documentation. I would need to explicitly disable and re-enable explicit rules, which is a bit painful, as a user.

@boneskull commented on GitHub (Jun 6, 2019): I have a feeling this is user error, but that's unclear from the documentation. I would need to explicitly disable and re-enable explicit rules, which is a bit painful, as a user.

kerem commented

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

Author

Owner

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

This definitely sounds like the wrong behavior for your scenario, but I’m afraid I may have done it this way for a reason. I’ll need to review the code and maybe think about this a little. Thanks for the very detailed report and investigation!

@DavidAnson commented on GitHub (Jun 6, 2019): This definitely sounds like the wrong behavior for your scenario, but I’m afraid I may have done it this way for a reason. I’ll need to review the code and maybe think about this a little. Thanks for the very detailed report and investigation!

kerem commented

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

Author

Owner

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

It’s slowly coming back to me… I think we agree that “enable“ of a single rule should turn that rule on no matter what else happened before? So then doesn’t it make sense that “enable” of all rules would do the same? OK, maybe not, but I think that’s the motivation behind the current behavior. What I may need to do is add some kind of a push/pop or save/restore ability for the scenario you’re dealing with.

@DavidAnson commented on GitHub (Jun 6, 2019): It’s slowly coming back to me… I think we agree that “enable“ of a single rule should turn that rule on no matter what else happened before? So then doesn’t it make sense that “enable” of all rules would do the same? OK, maybe not, but I think that’s the motivation behind the current behavior. What I may need to do is add some kind of a push/pop or save/restore ability for the scenario you’re dealing with.