mirror of
https://github.com/DavidAnson/markdownlint.git
synced 2026-04-25 09:16:02 +03:00
[GH-ISSUE #787] MD034/no-bare-urls false positive since v0.7.0 #533
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#533
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 @MichaIng on GitHub (Apr 22, 2023).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/787
This code produces an error since v0.7.0:
Or are there Markdown parsers which do not support brackets within the link text brackets? In case, is there a proper way to escape them?
@DavidAnson commented on GitHub (Apr 22, 2023):
Per the specification, if "text" were a valid shortcut link, then it would bind more tightly than the outer link and this error message would be correct.
Example here: https://dlaa.me/markdownlint/#%25m%23%20Issue%20150%0A%0A%5B%5Btext%5D%20text%5D(https%3A%2F%2Fsome.url.org)%0A%0A%5Btext%5D%3A%20https%3A%2F%2Fexample.com%0A
In this case, "text" is not a valid shortcut link, but because the linter assumes all shortcut links are valid even if undefined (needed for other reasons), it produces this misleading output.
@DavidAnson commented on GitHub (Apr 22, 2023):
As you suggest, it is perfectly valid to escape the inner brackets like so to avoid the warning: https://dlaa.me/markdownlint/#%25m%23%20Issue%20150%0A%0A%5B%5C%5Btext%5C%5D%20text%5D(https%3A%2F%2Fsome.url.org)%0A
@MichaIng commented on GitHub (Apr 22, 2023):
Interesting, I never knew about shortcut links. Is there an overview for them or is this something which can/needs to be defined in the Markdown document itself?
In the actual case it was
[[OS] other text](URL), so[OS]within the link text.I'll use the backslash escaping then, thanks for the hint 🙂.
@DavidAnson commented on GitHub (Apr 22, 2023):
https://spec.commonmark.org/0.30/#shortcut-reference-link
@MichaIng commented on GitHub (Apr 22, 2023):
Okay makes all sense now. Since Markdownlint cannot know which shortcuts are valid and which not (unless it really interprets the whole document first), it assumes this syntax to be always a valid shortcut. And I think it is even fine like this, since brackets within link text should then simply always be escaped as best practice. Otherwise a shortcut added at a later time may break things.
Only suggestion then, since links within link text are generally wrong: What about adding a new rule which does not allow unescaped brackets (including shortcut links) within link text? This of course means that such shortcuts are not expanded within link text, to be able to detect it. I guess, currently things are (usually correctly) expanded from inside to outside, so after expanding the internal shortcut, the outer link text syntax becomes invalid so that the URL is seen as no-bare-urls violation.
@DavidAnson commented on GitHub (Apr 22, 2023):
I don't know how widespread this is, but I would like to avoid the false positive you report because one of the main goals is to avoid bothering people if they have valid Markdown. Your point about behavior changing if a shortcut link suddenly becomes valid is reasonable, but that would be true anywhere in the document and I don't think I want to recommend escaping everywhere to prevent that.
@MichaIng commented on GitHub (Apr 22, 2023):
Okay, this means markdownlint needs to check for defined shortcut links. A limitation is that there are (non-standard) Markdown extensions to include one document into another. Especially for such definitions which are likely used across a whole website instead of a single page only, I guess such extensions are not rarely used: https://facelessuser.github.io/pymdown-extensions/extensions/snippets/
@DavidAnson commented on GitHub (Apr 22, 2023):
That's not an issue for now - this tool supports CommonMark and popular GFM extensions.
@NomarCub commented on GitHub (May 8, 2023):
I also have some links with brackets in their text (that are not shortcuts) that I'm used to working as normal.
I found this CommonMark rule relevant: https://spec.commonmark.org/0.30/#link-text
And checked the CommonMark dingus against the markdownlint one.
@MichaIng commented on GitHub (Jun 2, 2023):
Makes sense. Many thanks for looking into it and the clarification.