Если в ссылке содержится более одной точки, композер не знает, как обрабатывать её после второй точки. Например, как в этом случае:
Это ошибка или особенность?
https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf
Похоже, вы использовали эффект выделения, написав canine_pancreatitis, как этот текст.
1 лайк
Курсив появился из-за нижнего подчеркивания после второй точки. Если обернуть ссылку в < >, она, по-моему, отобразится корректно:
<https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al._canine_pancreatitis_-_review.pdf>
4 лайка
Каждый день что-то новое. Я не знал, что нижнее подчеркивание тоже делает курсив.
Так что… это фича, а не баг 
1 лайк
Что ж, автоматическая гиперссылка путается из-за нескольких точек в ссылке на PDF и начинает интерпретировать следующие подчеркивания как разметку Markdown, что может быть нежелательно?
Но экранирование с помощью <> — хорошее обходное решение, если оно вам нужно. 
2 лайка
Это вопрос, который отслеживает @Vitaly. Всё зависит от того, насколько распространены такие проблемы. Если это 1 из миллиона ссылок, то улучшать линкификатор не стоит. Если же 1 из 10, то определённо стоит.
4 лайка
Это зависит от ситуации. Если нужно делиться научными ссылками и PDF-файлами, как на моём форуме, то это действительно распространённая практика, охватывающая почти каждую ссылку. В противном случае это встречается не так часто, но использование более чем одной точки тоже не редкость.
С моей точки зрения — есть ли какая-то причина, почему достаточно указывать http:// или https:// в начале и заканчивать пробелом, плюс, конечно же, разрешённые форматы файлов?
Правила сложны и постоянно меняются.
Ссылкообразователь также работает без префикса https://, что добавляет лишней сложности.
Я предполагаю, что мы могли бы что-то сделать, чтобы смягчить поведение ссылкообразователя в случае с префиксом https://, но оставим решение за Виталием.
1 лайк
В этом-то и суть 
Я пытаюсь научить пользователей использовать < и >. Главная проблема с точки зрения UX заключается в том, что Discourse во многих случаях ведёт себя не так, как ожидают пользователи. Но это вопрос гораздо глубже, чем просто запоминание того, когда ссылки работают, а когда нет.
Мне это кажется логичным. Думаю, допустимо линифицировать только чистые имена хостов, а для URL с путём требовать наличие http.
Я записал тест-кейс, но с высокой вероятностью это та же проблема с акцентированием, что и раньше.
В целом, все ссылки с протоколом http(s):// можно исправить, и я приступаю к этому очень скоро (честно).
Для нечётких ссылок реалистичного решения нет (и это откроет дверь для ReDoS). Но, как я уже не раз говорил, добавленная ценность этого режима неочевидна, и он отключён по умолчанию из-за множества побочных эффектов. Я реализовал его только потому, что другие пакеты предлагали такую функцию.
1 лайк
Я считаю, что решение проблемы с http(s):// даст огромную отдачу.
Подавляющее большинство людей просто копируют URL из адресной строки браузера, и в нём обязательно указан протокол.
1 лайк
Действительно. Я не знаю реальных случаев, когда ссылки без протокола могут быть полезны.
Обычно это нужно для редких случаев, когда пользователи помнят домен и просто хотят его ввести. Обычно путь не участвует, параметр запроса… почти никогда.
Например:
Привет… ты заходил на discourse.org?
2 лайка
По моему мнению, заставлять таких пользователей вводить https:// для таких ссылок проще, чем бороться с побочными эффектами режима нечёткого поиска.