If a link has more than one dot, composer don’t know how to handle it after second dot. Like this one:
https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf
Bug or feature?
https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf
I think you used emphasis effect writing canine_pancreatitis. like this text.
The italics are because of the underscore after the second period. If you wrap the link in < > I think it displays properly:
<https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al._canine_pancreatitis_-_review.pdf>
Every day something new. I didn’t know underscores does italic too.
So… it is feature, not bug 
Well, the auto-linking is getting confused by the multiple periods in the pdf link, and starts reading the following underscores as markdown, which might not be desirable?
But the escape <> wrap is a good workaround if you need it. 
It is something that @Vitaly ia tracking, really depends on how common these issues are. If it is 1 in a million links it is not worth improving the linkifier, if it is 1 in 10 it certainly is
It depends. If there is need to share scientific links and pdfs, as on my forum, it is really common covering almost every link. Otherwise, not so often but more than one dot is not so rare form either.
From my point of view — is there some reason why starting http:// or https:// and ending to a space is not enough, plus allowed fileforms of course?
The rules are complex and evolving.
The linkifier also works without https:// prefix to add extra complexity.
I suspect that we could do something to relax the linkifiers behaviour for the https:// prefix case, but will leave Vitaly to weigh in.
That is somehow my point 
Well, I’m trying to teach users to use < and >. The biggest UX’ish issue here is Discourse starts to act in many cases too differently than users are expecting. But that is much deeper thing than just trying to remember when links work and when not.
That makes sense to me. I think it mount be ok to only linkify bare host names and require urls with a path to have http.
I’ve recorded test case but with high probability it’s the same emphasis-based issue as before.
In general, all links with protocol http(s):// can be fixed, and i start working on this very soon (really).
Fuzzy links have no realistic solution (and will open door to ReDoS). But, as i said many times, added value of this mode is not obvious, and it’s disabled by default because of many side effects. I did it only because other packages provided it.
I think resolving the http(s):// case will give enormous amounts of mileage.
Vast majority of people are just copying a URL from the address bar of the browser, it certainly includes protocol.
Indeed. I don’t know real cases where links without protocol can be useful.
It is usually for edge cases where users remember a domain and just want to type it in. Usually a path is not involved, a query param … almost never.
Eg:
Hey… did you check out discourse.org
IMO forcing such users to type https:// for such links is more simple, than fighting side effects of fuzzy mode.