MD044: Proper name matched in Hugo-style relref links
hussainweb opened this issue · comments
This is somewhat related to #329 and #443.
I have the proper-names rule set up for MD044 the usual way:
proper-names:
code_blocks: false
names:
- Example
The regular Markdown links work fine. But this fails when I try to use Hugo's link syntax. I have created an example on markdownlint demo.
Thanks for the example! As you note, the issue is with a Hugo-specific syntax which is not part of CommonMark or GFM and therefore not recognized. You may wish to disable this rule for that line or file or project.
(If this pattern is common, you could also add ".pdf" to the allow-list.)
Thank you for the quick response. My thought process here is that since the link syntax is still the same, this is something that is not necessarily incompatible with Markdown standards. (I am not an expert though and happy to be corrected.) At the same time, I recognize that this is unusual. If it is compatible with the link syntax ([text](<link>)), I am hoping that a parsing change here will allow it to work with the usual link syntax, regardless of what appears inside <link>.
Again, I am neither an expert nor a maintainer. The above is just a theory of how it could work. If you think this is workable, I'll appreciate it very much. FWIW, I am not facing issues with version 0.32.2 of the markdownlint-cli (corresponds to 0.26.2 of markdownlint).
This library is moving to use micromark for Markdown parsing: https://github.com/micromark/micromark
Searching very briefly, I do not see that anyone has added support for Hugo syntax: https://www.npmjs.com/search?q=Micromark%20Hugo%20
Thanks for the tip. I also think I was not entirely clear in my initial message. I am not asking to support Hugo syntax here. I only used that to show the problem. In my view, the parser should just interpret everything between the two braces ( and ) as a link and then not match proper names there. This already works for regular links but it breaks if special characters such as { and < come in.
Moreover, if you are moving to micromark for parsing, maybe they already handle this and you don't have to do anything. I will wait for the move and stick with the old version of the CLI for now.
Question: is there a planned release for micromark parsing or is it uncertain right now?
This rule has already been converted to use the micromark parser. The issue is that the Hugo syntax here is not a valid link according to the CommonMark specification: https://spec.commonmark.org/0.30/#links. Because it is not a valid link, it is treated as normal text and does not get the special treatment links do. If Hugo support were incorporated into micromark as an extension, this syntax would presumably be recognized as a link and the behavior you want would automatically result.
Thanks. That was very helpful. I found this (emphasis added):
A link destination consists of either
...
a nonempty sequence of characters that does not start with <, does not include ASCII control characters or space character, and includes parentheses only if (a) they are backslash-escaped or (b) they are part of a balanced pair of unescaped parentheses.
This means that the only reason this does not get parsed as a link is because of the space. There are no ASCII control characters and the parentheses are balanced.
Moreover, it turns out that Hugo doesn't care about spaces at all. So, if I remove all the spaces, it works for both markdownlint and Hugo. Example.
Still, I think this is hacky. Removing spaces in the beginning and end is one thing but it is very weird to remove the space between relref and the path. Like this: [Link 3]({{<relref'docs/organization.pdf'>}}).
So, I think my best option is to ignore the line with markdownlint-disable-next-line.
I'm okay to close this unless you have other ideas. I hope this finding is useful to someone or to me in the future 😀.
It's great that you figured that out! I assumed spaces were required and didn't think to suggest removing them. Good for you experimenting. :) I will go ahead and close this issue.