-
-
Notifications
You must be signed in to change notification settings - Fork 697
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MD013 false positive when url contains # #1154
Comments
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: |
…ario and be more explicit about strict/stern behavior (refs #1154).
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 |
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:
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: true and 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 ## 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 |
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., Also, it IS acceptable to include a line break in the link text: |
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. |
When the
.markdownlint.yaml
contains the followingand my markdown contains the following 2 lines:
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 text was updated successfully, but these errors were encountered: