-
-
Notifications
You must be signed in to change notification settings - Fork 314
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
Increase Precedence of shortcut link references over full and compact for defined link references #663
Comments
I’m personally on the other side of this (#653) |
The current rules prevent shortcuts from forming links by not allowing them if they’re followed by an empty ( However, I think your idea here is to prefer shortcuts, if they could be valid. Regardless of what they’re followed with. |
Hrm. Empty brackets after a shortcut link are, in fact, the original shortcut design for Markdown itself; shortcuts without them were implemented but never documented, IIRC (but quite popular, IIRC). In fact, adding them where how I worked around this issue in my project (theory/justatheory@5e673f1). But yes, my preference is to try to follow what the document author likely means: If the shortcut is defined, preferentially resolve it, especially if an alternative interpretation does not resolve to a shortcut reference. I believe it will then be less surprising to the author, and more closely follow what they mean. |
Sorry, to clarify my intent: I do not propose removing shortcuts. I’m fine with shortcuts ( Note also, that neither my proposal, nor your proposal, nor CM, resembles how references worked in Markdown.pl: [w][n] [x][y], [z][ ]
[w]: a
[x]: b
[y]: c
[z]: d Yields (in <p><a href="a">w</a>[n] <a href="c">x</a>, <a href="d">z</a>[ ]</p> Yields (CM spec in my understanding): <p>[w][n] <a href="c">x</a>, <a href="d">z</a>[ ]</p> Yields (CM.js): <p>[w][n] <a href="c">x</a>, [z][ ]</p> Yields (your proposal, I believe): <p><a href="a">w</a>[n] <a href="b">x</a><a href="c">y</a>, <a href="d">z</a>[ ]</p> |
Yes, that seems like a fair representation. I agree that brackets with empty space shouldn't resolve to anything. Pasting your example into Babelmark 2, it looks like |
Oh didn’t know there’s a babelmark@2. Works for me. 🤷♂️ Maybe try a different browser? Or, maybe this is obvious but just to be sure: it groups renderings with the same output together |
babelmark 1 (dead) |
🤦🏻♂️ Of course. Was not obvious to me, but is now that you say it. Easier for me to realize in bablemark 3 (thanks @vassudanagunta!). Fascinating that none of them produce either my or your suggested interpretations. Gotta love edge cases! |
Followup to this discussion as well as yuin/goldmark#143. The idea is to give higher precedence to shortcut link references when they actually resolve to a link defined in the document, so as to give priority to the links as defined by the author, rather than to the rules for parsing the links references themselves. Where ambiguity cannot be resolved by link definitions, the precedence should be as before. Examples follow.
Example 561
Current output:
Desired output:
Reason: The author has made explicit definitions for the
foo
andbar
links, so both should take precedence over[foo][bar]
, as it's more likely to reflect the author's intent.Example 567
Current output:
Desired output:
Reason: The author has made explicit definitions for the
baz
andfoo
links but notbar
, so[foo]
and[bar]
should take precedence over[bar][baz]
, as it's more likely to reflect the author's intent.Footnote Example
Current output:
Desired output:
Reason: The author has made explicit definitions for both the
[Foo]
link and the[^1]
footnote, so both should be rendered, rather than prioritizing[Foo][^1]
as a full reference, especially since[^1]
fails to resolve to a link at all. Again, the intention here is to better approximate the likely intent of the author. (I realize that CM does not define a footnote syntax, but I suspect it its CM's precedence rules that interfere with the expected footnote output.)The text was updated successfully, but these errors were encountered: