mirror of
https://github.com/DavidAnson/markdownlint.git
synced 2026-04-25 09:16:02 +03:00
[GH-ISSUE #703] Rule MD013 fails with long blocks comments in v0.27.0 #2364
Labels
No labels
bug
enhancement
enhancement
enhancement
fixed in next
fixed in next
fixed in next
new rule
new rule
new rule
pull-request
question
refactoring
refactoring
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/markdownlint#2364
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @svg153 on GitHub (Jan 18, 2023).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/703
Problem Description
What is actually happening
With new markdownlint v0.27.0 the
MD013rule fails with long block comments more than line length configured.What is the expected behavior
Work as previous version markdownlint v0.26.2:
MD013rule does not fail with comment blocks longer than the maximum configured line.Context
We are using pre-commit in our CI, and we have a workflow to detect new pre-commit hooks versions. This workflow detects the new markdownlint-cli v0.33.0, and creates a PR.
In this PR, pre-commit runs with the new markdownlint-cli hook version v0.33.0 and fails checking the
MD013:But in this file there is a comment:
I investigate a little bit...
MD013rule was updated too.(changelog diffMD013.mdrule or other global configuration.test/MD011-MD021.mdfileQuestions
@DavidAnson commented on GitHub (Jan 18, 2023):
This doesn't seem to have been an intended change looking at the history of that release on my phone, but I'm also not sure it's wrong. That comment line exceeds the configured line length, so the warning you see is appropriate. You ask about a way to suppress checking comments, but why not Wrap your comment line to the configured length? I'd rather not add another parameter if it's not needed. Another option would be to use the inline comments to disable/restore the rule just around your comment, but that will be annoying if you have many of these.
I will have a look to see when/why this started, but I'm not sure I will change the behavior.
@svg153 commented on GitHub (Jan 23, 2023):
Thank you very much.
Our problem was that we had many files with that error. With your answer, we have proceeded to change all the files.
It might be interesting to write a test case for this case to define its behavior ? If not, we could close this issue.
@DavidAnson commented on GitHub (Jan 23, 2023):
Yes, I will add a test when I investigate this.
@DavidAnson commented on GitHub (Feb 26, 2023):
Note to self:
f0bb4c639bintroduces the regression according togit bisect. Very brief visual review suggestsnotSpaceCrLfReis the cause.@DavidAnson commented on GitHub (Feb 27, 2023):
After some thought, I am going to leave the new behavior alone. Someone who enables the line-length rule wants to know when their lines are too long. There are some constructs today that can get an exception (code, headings, tables), but they are all things that can be difficult to reduce the line length for. Most comment scenarios should be pretty amenable to shortening (as you seem to have done in your project), so I am NOT going to add an exclusion at this time. I WILL add a test case for this like you suggest and will use that to close the issue. Thank you for bringing this up!