MD013 false positive when url contains #
SimonMarynissen opened this issue · comments
When the .markdownlint.yaml contains the following
MD013:
line_length: 80
heading_line_length: 80
code_block_line_length: 80
code_blocks: true
tables: true
headings: true
strict: false
stern: trueand my markdown contains the following 2 lines:
[Ok](https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml)
[Not ok](https://github.com/DavidAnson/markdownlint/blob/main/schema/.markdownlint.yaml#L61-L77)eventhough both lines are more than 80. Of course links can't be made shorter and as such both links should not be reported.
The "Not ok" example above CAN be shortened by removing the space character or turned into a non-breakable line by replacing the space with a newline character. If either is done, MD013 does not report a violation:
That's indeed the case, but there is still an inconsistency: both lines are over the limit, but only the URL with the # in it is reported. I would suspect either both of them or neither of them to be reported.
Since both lines have no spaces in them and I run with strict = false and stern = true it should report none of them.
I updated the documentation for this rule last night to try to clarify two points (see link above), but this is the relevant part from the published package documentation and was not changed:
To warn for lines that are too long and could be fixed but allow long lines without spaces, set the stern parameter to true.
The first line of your example is too long without spaces, so is allowed; the second line of your example is too long and could be shortened, so is reported. The behavior you report is behaving as documented for for your configuration.
With the following configuration
MD013:
line_length: 30
heading_line_length: 30
code_block_line_length: 30
code_blocks: true
tables: true
headings: true
strict: false
stern: trueand markdown document:
## Title with size equal limit
[ok](https://example.com)
[also ok](https://example.com)
[ok](https://example.com/extra)
[not ok](https://example.com/extra)
[also_ok](https://example.com/extra)What I don't like about this behavior is that the one that is not ok, cannot be broken at the space that causes it to be reported. You can only break the link after ( and before ).
The most logical handling (in my opinion) would be the same behaviour for the last three lines. Because all three lines can be broken at the parentheses to get inside the limit:
## Title with size equal limit
[ok](
https://example.com/extra)
[not ok](
https://example.com/extra)
[also_ok](
https://example.com/extra)I would suggest to report neither of the three with the current settings. Every line that has no breakable spaces should not be reported when stern = true and strict = false.
This rule is based on line-breaking via whitespace - a technique pretty much everybody knows about. I think very few people know about breaking within the link destination as you show above and I would not want to confuse people. In the case of links, I think reference links (i.e., [link][reference]) are a better approach than inline links because their shorter length tends to make discussions like the above unnecessary.
Also, it IS acceptable to include a line break in the link text:
https://dlaa.me/markdownlint/#%25m%23%20Heading%0A%0A%5Bperfectly%0Afine%5D(https%3A%2F%2Fexample.com%2F)%0A
I didn't know you could break in the link text. There are downsides to reference links as well though, and I suppose that markdownlint is meant to lint all kind of markdown files. But for this issue, I guess I'll format my links differently then to avoid this situation, but it doesn't feel ideal.
(Deleted SPAM comment)
@DavidAnson You can close the issue if you want.