-
Notifications
You must be signed in to change notification settings - Fork 868
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
Cannot use inline code tags inside of reference links #280
Comments
@twolfson, thanks for your report. I agree that this would appear to be a bug a first glance. However you should note that the syntax documentation states:
Note that it does not say that they may consist of markdown markup, which may or may not be different than "punctuation" (depending on the implementation). In fact, the various regex based implementations appear to have the same behavior. The way the regexparsers work is that they run one regular expression against the source text after another. Of course, so that markdown syntax can be enclosed in code tags, the code regex runs first. That means that the text between the brackets will be changed before the parser even looks for reference style links. Thus it will no longer match the reference name and will not be recognized as a reference style link1. I'm not aware of any way to work around this except by starting from scratch with a completely different parsing method (top-down, Left-to-Right, PEG, etc. — methods used by the implementations which do not exhibit this behavior). As the original implementation (markdown.pl) works this way, I see no reason to change. After all, if you need to have code inside a link, you can use a reference name in the second set of brackets. That works in all implementations. For the reasons stated above and given that a minor adjustment to the source text works around this, I am closing this wontfix. Footnotes
|
It is good to know that explicit reference links work. For what it's work GFM does support this behavior. Thank you for your consideration.
|
In 28c9263 I introduced automatic linkification of option references in rule documentation, which automatically converted the following: ## Options * `namespace-packages` to: ## Options * [`namespace-packages`] [`namespace-packages`]: ../../settings#namespace-packages While the above is a correct CommonMark[1] link definition, what I was missing was that we used mkdocs for our documentation generation, which as it turns out uses a non-CommonMark-compliant Markdown parser, namely Python-Markdown[2], which contrary to CommonMark doesn't support link definitions containing code tags.[3] Mkdocs doesn't support CommonMark[4][5]. This commit therefore switches our documentation to use mdbook[6] instead, which uses the pulldown-cmark[7] CommonMark implementation, sparing us from having to deal with such parser idiosyncracies. [1]: https://commonmark.org/ [2]: https://github.com/Python-Markdown/markdown/ [3]: Python-Markdown/markdown#280 [4]: mkdocs/mkdocs#361 [5]: mkdocs/mkdocs#1835 [6]: https://github.com/rust-lang/mdBook [7]: https://github.com/raphlinus/pulldown-cmark
In 28c9263 I introduced automatic linkification of option references in rule documentation, which automatically converted the following: ## Options * `namespace-packages` to: ## Options * [`namespace-packages`] [`namespace-packages`]: ../../settings#namespace-packages While the above is a correct CommonMark[1] link definition, what I was missing was that we used mkdocs for our documentation generation, which as it turns out uses a non-CommonMark-compliant Markdown parser, namely Python-Markdown[2], which contrary to CommonMark doesn't support link definitions containing code tags.[3] Mkdocs doesn't support CommonMark[4][5]. This commit therefore switches our documentation to use mdbook[6] instead, which uses the pulldown-cmark[7] CommonMark implementation, sparing us from having to deal with such parser idiosyncracies. [1]: https://commonmark.org/ [2]: https://github.com/Python-Markdown/markdown/ [3]: Python-Markdown/markdown#280 [4]: mkdocs/mkdocs#361 [5]: mkdocs/mkdocs#1835 [6]: https://github.com/rust-lang/mdBook [7]: https://github.com/raphlinus/pulldown-cmark
In 28c9263 I introduced automatic linkification of option references in rule documentation, which automatically converted the following: ## Options * `namespace-packages` to: ## Options * [`namespace-packages`] [`namespace-packages`]: ../../settings#namespace-packages While the above is a correct CommonMark[1] link definition, what I was missing was that we used mkdocs for our documentation generation, which as it turns out uses a non-CommonMark-compliant Markdown parser, namely Python-Markdown[2], which contrary to CommonMark doesn't support link definitions containing code tags.[3] Mkdocs doesn't support CommonMark[4][5]. This commit therefore switches our documentation to use mdbook[6] instead, which uses the pulldown-cmark[7] CommonMark implementation, sparing us from having to deal with such parser idiosyncracies. [1]: https://commonmark.org/ [2]: https://github.com/Python-Markdown/markdown/ [3]: Python-Markdown/markdown#280 [4]: mkdocs/mkdocs#361 [5]: mkdocs/mkdocs#1835 [6]: https://github.com/rust-lang/mdBook [7]: https://github.com/raphlinus/pulldown-cmark
It looks like reference links work and inline code + inline links work but a combination of the two does not.
Working:
Not working:
The expected output of the above is the same as the output of the second
The text was updated successfully, but these errors were encountered: