# Markup collision with underscores in link texts **URL:** \ **Category:** Spec\ **Created:** [January 18, 2015, 8:28am UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016 "2015-01-18T08:28:10Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![vitaly](https://talk.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [January 18, 2015, 8:28am UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/1 "2015-01-18T08:28:10Z")
[Example](http://spec.commonmark.org/dingus.html?text=http%3A%2F%2Fmedia.ccc.de%2Fbrowse%2Fcongress%2F2014%2F31c3_-_6373_-_en_-_saal_6_-_201412291600_-_the_only_thing_we_know_about_cyberspace_is_that_its_640x480_-_olia_lialina.html) ```auto http://media.ccc.de/browse/congress/2014/31c3_-_6373_-_en_-_saal_6_-_201412291600_-_the_only_thing_we_know_about_cyberspace_is_that_its_640x480_-_olia_lialina.html ``` Is it possible to avoid emphasis for such case without direct autolink markup? Formaly, spec works as expected, but such link texts happens quite often (space replaced with underscores). Ticket in markdown-it [linkify doesn't accept urls with underscores · Issue #38 · markdown-it/markdown-it · GitHub](https://github.com/markdown-it/markdown-it/issues/38). ---
**Author:** ![Knagis](https://talk.commonmark.org/letter_avatar_proxy/v2/letter/k/ba9def/32.png) [@Knagis](https://talk.commonmark.org/u/Knagis)\ **Post date:** [January 18, 2015, 1:24pm UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/2 "2015-01-18T13:24:46Z")
Could a solution be that ASCII symbols (with the exception of `_` and `*`) are added to the exception of `ASCII alphanumeric` characters that disallow `_` or `__` being considered as opener or closer? In your example it would be `-` that would prevent the emphasis. ---
**Author:** ![vitaly](https://talk.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [January 18, 2015, 2:00pm UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/3 "2015-01-18T14:00:57Z")
Probably, `-` can be added to alphanumeric exclusions, but i don’t know is it safe or not. Adding [a-z] to any rules is bad idea in general, because will fail with other languages. ---
**Author:** ![Knagis](https://talk.commonmark.org/letter_avatar_proxy/v2/letter/k/ba9def/32.png) [@Knagis](https://talk.commonmark.org/u/Knagis)\ **Post date:** [January 18, 2015, 2:48pm UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/4 "2015-01-18T14:48:01Z")
I think that the origin of the current [a-z0-9] rule is because `_` is often used in member names from code. Almost always they will be ASCII, not unicode. But since the rule is there, most people would assume that `a_a_a` and `ā_ā_ā` would work the same so it could perhaps changed to any non-whitespace… [Babelmark2](http://johnmacfarlane.net/babelmark2/?normalize=1&text=a_a_a%0A%0A%C4%81_%C4%81_%C4%81) - actually CommonMark ir the minority in this aspect - most of the others result in either emphasis for both or none for both. ---
**Author:** ![vitaly](https://talk.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [January 18, 2015, 3:27pm UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/5 "2015-01-18T15:27:22Z")
[a-z0-9] also covers english words in text. Probably, it will be more simple to remove it at all, and tune negative condition like [punctuation + scopes + whitespaces]. Looks like goal was to define “word bounds” with cheats. That’s, not a problem in normal regegp engines, but pain in JS. ---
**Author:** ![jgm](https://talk.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [January 18, 2015, 4:23pm UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/6 "2015-01-18T16:23:19Z")
@Knagis’s solution would work for this case, but there would be other bare URLs containing underscores for which this problem would arise again. [EDIT: A further problem is that the solution would be overly restrictive: I think we want to allow people to do things like `_word_---blah blah` and `_foo_-bar`.] This is a tough one. It does show one problem with the idea that bare URLs should be linkified after parsing (not in the parser itself). Probably those who want to linkify bare URLs should insert the linkifying routine into the parser to avoid these problems—though there would, I imagine, be a significant performance cost. (That’s what cheapskate does, and you can see that it renders this nicely on [BabelMark2](http://johnmacfarlane.net/babelmark2/?normalize=1&text=http%3A%2F%2Fmedia.ccc.de%2Fbrowse%2Fcongress%2F2014%2F31c3_-_6373_-_en_-_saal_6_-_201412291600_-_the_only_thing_we_know_about_cyberspace_is_that_its_640x480_-_olia_lialina.html%0A). I don’t see a good solution; I’m tempted to say that users who want URLs with underscores will just have to put them in `<...>`. ---
**Author:** ![jgm](https://talk.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [January 18, 2015, 4:56pm UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/7 "2015-01-18T16:56:41Z")
+++ Kārlis Gaņģis [Jan 18 15 15:01]: > I think that the origin of the current [a-z0-9] rule is because `_` is often used in member names from code. Almost always they will be ASCII, not unicode. But since the rule is there, most people would assume that `a_a_a` and `ā_ā_ā` would work the same so it could perhaps changed to any non-whitespace… Yes, the intent was to avoid capturing underscores in code identifiers as emphasis, since that’s the case I was aware of that was prompting people to complain. I hadn’t considered this URL case. Given the new rules for emphasis, I wonder if it would make sense to simplify the rules for `_` emphasis thus: instead of > A single `_` character can open emphasis iff it is part of a left-flanking delimiter run and is not preceded by an ASCII alphanumeric character. we could have: > A single `_` character can open emphasis iff it is part of a left-flanking delimiter run and not part of a right-flanking delimiter run. and so on. We’re already doing the checks for left- and right-flankingness, so this would not add any complexity to the code; it would even simplify it. [EDIT: Just to clarify, this suggestion would not prevent emphasis in the original URL example. It just seemed independently preferable to singling out ASCII alphanumerics.] [UPDATE: I have now made this change.] ---
**Author:** ![vitaly](https://talk.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [March 6, 2015, 5:34am UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/8 "2015-03-06T05:34:31Z")
@jgm, need your advice. I’ve tried to detect links with schemas on inline phase, but got another collision. Such links eat tailing markup from pairs: - `_http://foo.com/_` - `*http://foo.com/*` - other pairs from extentions (^, ~, ~~, ==, ++) Any ideas how to solve such conflict? Looks like it would be more effective to disable emphasis on this pattern inside of text: `_-_` ---
**Author:** ![jgm](https://talk.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [March 6, 2015, 7:36am UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/9 "2015-03-06T07:36:08Z")
@vitaly, I’m not quite sure I understand your question. But, as I’ve said before, the biggest problem with linkifying bare URLs is figuring out what final punctuation is part of the link and what is not. You can introduce heuristics for this, but you’ll never cover all cases. This is why I prefer not to linkify bare URLs. ---
**Author:** ![vitaly](https://talk.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [March 6, 2015, 7:58am UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/10 "2015-03-06T07:58:18Z")
Likification logic is ok. Problem is with emphasis. As you said, `_` has additional restrictions, to avoid false\_positives\_inside\_of\_words. Reason is clear. I think, here can be one more exclusion - skip `_-_` inside of words. Because this pattern can happen in human-friendly links, generated from article titles: ```auto http://media.ccc.de/browse/congress/2014/31c3_-_6373_-_en_-_saal_6_-_201412291600_-_the_only_thing_we_know_about_cyberspace_is_that_its_640x480_-_olia_lialina.html ``` That looks more safe, than setting high priority to likifier and cheating with link tails. I don’t insist, that this should be in spec. Only ask your opinion - do you see problems with such logic? At first glance, i can’t find cases, when user need emphasis for 2 words with dash between. ---
**Author:** ![jgm](https://talk.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [March 6, 2015, 6:09pm UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/11 "2015-03-06T18:09:02Z")
Seems to me that the best approach would be to scan for links as a unit rather than hoping nothing inside the link will be interpreted as Markdown. Anyway, I can imagine cases where you’d want underline emphasis next to a hyphen. (Especially when we have multiple hyphens, an ASCII em or en dash, but even with single hyphens.) ---
**Author:** ![vitaly](https://talk.commonmark.org/user_avatar/talk.commonmark.org/vitaly/32/396_2.png) [@vitaly](https://talk.commonmark.org/u/vitaly)\ **Post date:** [March 6, 2015, 6:49pm UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/12 "2015-03-06T18:49:01Z")
I tried this approach [hear](https://github.com/markdown-it/markdown-it/commit/f976792e547f2ebd6beea96d8d81aec9674659c3#diff-21f9532ef2808872065a4498205197dfR19). Problem is, that we don’t know where to stop, and linkifier eats markdown markup on tail. Parser can have extentions, adding ++, == etc to existing \_, \_\_, \*, \*\*. Much more possibilities for mistake. Could you provide examples, which become broken if i disable `_-_` inside of words? ---
**Author:** ![jgm](https://talk.commonmark.org/user_avatar/talk.commonmark.org/jgm/32/1360_2.png) [@jgm](https://talk.commonmark.org/u/jgm)\ **Post date:** [March 6, 2015, 8:04pm UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/13 "2015-03-06T20:04:35Z")
+++ vitaly [Mar 06 15 18:59]: > I tried this approach [hear](https://github.com/markdown-it/markdown-it/commit/f976792e547f2ebd6beea96d8d81aec9674659c3#diff-21f9532ef2808872065a4498205197dfR19). Problem is, that we don’t know where to stop, and linkifier eats markdown markup on tail. Parser can have extentions, adding ++, == etc to existing \_, \_\_, \*, \*\*. Much more possibilities for mistake. Given that URLs can contain all kinds of symbols that have meaning in Markdown, including square brackets, parentheses, backslashes, and asterisks, it just seems crazy to allow the inside of a URL to be parsed as Markdown and then linkify afterwards. Disabling `_` emphasis next to a hyphen would be an ad hoc fix for just one possible issue of this kind. > Could you provide examples, which become broken if i disable `_-_` inside of words? ``` Spanish has two words that translate the English word _that_---_aquel_ and _eso_---so we need to see how they differ. I looked up every word from _A_-_Z_. See Plato, _Timaeus_, 17_a_-_d_. ``` I can think of lots of cases where people might naturally do this. ---
**Author:** ![Wilfred](https://talk.commonmark.org/user_avatar/talk.commonmark.org/wilfred/32/1108_2.png) [@Wilfred](https://talk.commonmark.org/u/Wilfred)\ **Post date:** [November 8, 2017, 11:19am UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/14 "2017-11-08T11:19:24Z")
I’ve been bitten by this for links referencing Python source code, e.g.: ``` http://example.com/ __init__.py ``` Several implementations produce the intended link here ([babelmark](http://johnmacfarlane.net/babelmark2/?normalize=1&text=http%3A%2F%2Fexample.com%2F __init__.py)), although `http://example.com/ __init__ ` seems to be harder to handle ([babelmark](http://johnmacfarlane.net/babelmark2/?normalize=1&text=http%3A%2F%2Fexample.com%2F __init__ )). ---
**Author:** ![Wilfred](https://talk.commonmark.org/user_avatar/talk.commonmark.org/wilfred/32/1108_2.png) [@Wilfred](https://talk.commonmark.org/u/Wilfred)\ **Post date:** [November 9, 2017, 3:50pm UTC](https://talk.commonmark.org/t/markup-collision-with-underscores-in-link-texts/1016/15 "2017-11-09T15:50:07Z")
Interestingly, GitHub’s commonmark dialect does not seem to suffer from this. Their formal specification briefly mentions underscores in its [autolink section](https://github.github.com/gfm/#autolinks-extension-): > Autolinks can also be constructed without requiring the use of \< and to \> to delimit them, although they will be recognized under a smaller set of circumstances. All such recognized autolinks can only come at the beginning of a line, after whitespace, or any of the delimiting characters \*, \_, ~, and (. This forbids things like ``http://example.com`` becoming a link. > After a valid domain, zero or more non-space non-\< characters may follow: This seems to imply `_` is not treated specially. > An extended email autolink will be recognised when an email address is recognised within any text node. Email addresses are recognised according to the following rules: […] `.`, `-`, and `_` can occur on both sides of the `@`, but only .`` may occur at the end of the email address, in which case it will not be considered part of the address: Email autolinks also get a specific mention regarding underscores.