Clarify: emphasis delimiters inside link destinations are literal#378
Clarify: emphasis delimiters inside link destinations are literal#378dereuromark wants to merge 2 commits into
Conversation
bdb9094 to
038b426
Compare
Add a note to the Precedence section explaining that inline formatting delimiters inside link destinations (URLs in parentheses) are treated as literal text and don't participate in emphasis matching. See jgm#375
038b426 to
c854d7c
Compare
|
@jgm This appears to still be open. I think with the merge of the others this should be good to go now. |
|
Looks good to me. It matches the test cases and the reference implementation and without this PR, I don't see a way to clearly argue why those should be correct. |
This risks being tautological. Once you've decided that It would be desirable to have another document that precisely specifies the syntax, but I think we may be in danger of confusing the purpose of this document if we try to do this sort of thing here.... |
Agreed, it's good to have one somewhat easily readable document the covers all normal syntax cases. Some ideas:
|
Reframe the note as a precedence/ordering statement (constructs resolved before emphasis matching) rather than a link-destination-specific rule. This avoids the tautology concern and covers code spans too, keeping the URL case as an illustration of the general rule.
|
The implementations are already fixed and merged, so the substantive bug is resolved regardless; this is now purely about documentation, happy to adjust the wording to stay non-tautological. |
Related: #375
JS implementation fix: jgm/djot.js#125
PHP implementation fix: php-collective/djot-php#81
Summary
Adds a clarifying note to the Precedence section of the syntax spec explaining that inline formatting delimiters inside link destinations are treated as literal text.
This covers the destination-only case:
_or*inside a URL like(http://example.com?foo_bar=1)does not participate in emphasis matchingThe bracket-text case (
_[bar_](url)) is intentionally not changed - emphasis continues to take precedence per the existing "first to start wins" rule.Per discussion in #375, this is the simpler fix that addresses the main real-world issue (URLs with underscores in query params) without the complexity of lookahead parsing.