Autolinking URLs with underscores does not produce the intended link #112

Activity

1. robinst commented on Nov 9, 2017

   

   robinst

   on Nov 9, 2017

   Collaborator

   More actions

   Hey, thanks for raising this.

   Yeah, this is a consequence of doing autolinking on the resulting text nodes (after inline parsing). So by the time we do autolinking, the <strong> already happened.

   If we did it the other way around, I'm pretty sure there would be cases where the result would be unexpected too. E.g. with the following Markdown:

   `http://example.com`
   

   Would you expect backticks + link + backticks or just inline code? I would expect the latter.

   I think with Markdown, there's always cases where the output doesn't match what the user expected. In your case, the workaround is simple, change it to this:

   <http://example.com/__init__.py>
   

   Markdown-it has the same problem. What other implementations with autolinking have you seen that handle it as you expect?
2. Wilfred commented on Nov 9, 2017

   

   Wilfred

   on Nov 9, 2017

   Last edited by Wilfred

   Author

   More actions

   You can compare implementations here: http://johnmacfarlane.net/babelmark2/?normalize=1&text=http%3A%2F%2Fexample.com%2F__init__.py, which shows that marked, cheapskate and a few others solve this.

   GitHub's markdown dialect, which is based on commonmark these days, also solves this problem (it's documented in their formal spec):

   http://example.com/__init__.py
   
   `http://example.com/__init__.py`
   

   Produces:

   http://example.com/__init__.py

   http://example.com/__init__.py

   I agree: I also wouldn't expect autolinking inside backticks. None of the markdown implementations (even those with autolinking) seem to create links inside backticks: http://johnmacfarlane.net/babelmark2/?normalize=1&text=%60http%3A%2F%2Fexample.com%2F__init__.py%60
3. robinst commented on Nov 10, 2017

   

   robinst

   on Nov 10, 2017

   Collaborator

   More actions

   In the babelmark link, the problem is that most implementations there such as commonmark.js don't do autolinking (or it's not enabled by default), so it's not really a good comparison. For example, markdown-it is in the second group, but if you enable it as I've done in the link I posted in my last comment, you can see that it has the same behavior as commonmark-java.

   Thanks for the GitHub link. Looks like they've tightly integrated autolinking in inline parsing. They trigger on : while inline parsing and if they find a URL, insert a link and continue normal inline parsing after the URL. See https://github.com/github/cmark/blob/master/extensions/autolink.c#L252 and https://github.com/github/cmark/blob/master/extensions/autolink.c#L201

   For us, that would be a biggish change, because it would mean making inline parsing extensible. Basically for each char that the core inline parser would treat as text, extensions would be checked to see if they want to parse it instead. If yes, they would be able to add/return nodes and advance the parsing position.

   Doing that may also allow other interesting uses. Having said that, I'm pretty sure I'm not gonna pick this up in the near future. But if someone else wants to have a go at it, I'm willing to mentor. Marking this as help wanted :).
4. robinst commented on Nov 10, 2017

   

   robinst

   on Nov 10, 2017

   Collaborator

   More actions

   I've opened a separate issue for making inline parsing extensible. I'm closing this one, we can reopen when the foundations are in place.
5. robinst

   closed this as completedon Nov 10, 2017