Skip to content
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

Closed
twolfson opened this issue Jan 18, 2014 · 2 comments
Closed

Cannot use inline code tags inside of reference links #280

twolfson opened this issue Jan 18, 2014 · 2 comments

Comments

@twolfson
Copy link

It looks like reference links work and inline code + inline links work but a combination of the two does not.

Working:

>>> markdown.markdown('[hello][]\n\n[hello]: world')
u'<p><a href="world">hello</a></p>'
>>> markdown.markdown('[`hello`](world)')
u'<p><a href="world"><code>hello</code></a></p>'

Not working:

>>> markdown.markdown('[`hello`][]\n\n[`hello`]: world')
u'<p>[<code>hello</code>][]</p>'

The expected output of the above is the same as the output of the second

u'<p><a href="world"><code>hello</code></a></p>'
@waylan
Copy link
Member

waylan commented Jan 18, 2014

@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:

Link definition names may consist of letters, numbers, spaces, and punctuation — but they are not case sensitive.

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

  1. Interestingly, the link regexes are run after the code regex, then all other inline markup (bold, italics, etc) after that. Therefore, all other inline markdown will work as a definition name (it's just seen as "punctuation"). However, this is more a happy coincidence than a requirement of the syntax rules.

@waylan waylan closed this as completed Jan 18, 2014
@twolfson
Copy link
Author

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.

hello

[`hello`][]

# This should have a closing bracket but GitHub is parsing it
[`hello`: world

not-my-profile added a commit to not-my-profile/ruff that referenced this issue Feb 13, 2023
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
not-my-profile added a commit to not-my-profile/ruff that referenced this issue Feb 14, 2023
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
not-my-profile added a commit to not-my-profile/ruff that referenced this issue Feb 14, 2023
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants