Si un lien contient plus d’un point, le compositeur ne sait pas comment le gérer après le deuxième point. Comme celui-ci :
Bug ou fonctionnalité ?
https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf
Je pense que vous avez utilisé un effet d’emphase en écrivant canine_pancreatitis. comme ce texte.
1 « J'aime »
Les italiques sont dues au trait de soulignement après la deuxième période. Si vous enveloppez le lien dans < >, je pense qu’il s’affiche correctement :
<https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al._canine_pancreatitis_-_review.pdf>
4 « J'aime »
Chaque jour son lot de nouveautés. Je ne savais pas que les tirets du bas servaient aussi à mettre en italique.
Alors… c’est une fonctionnalité, pas un bug 
1 « J'aime »
Eh bien, la liaison automatique est confuse par les points multiples dans le lien PDF, et commence à lire les tirets du bas suivants comme du markdown, ce qui n’est peut-être pas souhaitable ?
Mais l’échappement avec \u003c\\u003e est une bonne solution de contournement si vous en avez besoin. 
2 « J'aime »
C’est quelque chose que @Vitaly suit, cela dépend vraiment de la fréquence de ces problèmes. Si c’est 1 lien sur un million, cela ne vaut pas la peine d’améliorer le lien, si c’est 1 sur 10, cela en vaut certainement la peine.
4 « J'aime »
Ça dépend. S’il faut partager des liens scientifiques et des PDF, comme sur mon forum, c’est très courant et cela couvre presque tous les liens. Sinon, ce n’est pas si fréquent, mais plus d’un point n’est pas non plus une forme rare.
De mon point de vue — y a-t-il une raison pour laquelle commencer par http:// ou https:// et terminer par un espace n’est pas suffisant, en plus des formats de fichiers autorisés bien sûr ?
Les règles sont complexes et évoluent.
Le lienificateur fonctionne également sans le préfixe https:// pour ajouter une complexité supplémentaire.
Je soupçonne que nous pourrions faire quelque chose pour assouplir le comportement du lienificateur pour le cas du préfixe https://, mais je laisserai Vitaly donner son avis.
1 « J'aime »
C’est en quelque sorte mon propos 
Eh bien, j’essaie d’apprendre aux utilisateurs à utiliser < et >. Le plus gros problème de l’expérience utilisateur ici est que Discourse commence à agir dans de nombreux cas différemment de ce que les utilisateurs attendent. Mais c’est une chose beaucoup plus profonde que d’essayer de se souvenir quand les liens fonctionnent et quand ils ne fonctionnent pas.
Cela me semble logique. Je pense qu’il serait acceptable de ne créer des liens que pour les noms d’hôtes seuls et d’exiger que les URL avec un chemin aient http.
J’ai enregistré un cas de test mais avec une forte probabilité, il s’agit du même problème basé sur l’accentuation qu’auparavant.
En général, tous les liens avec le protocole http(s):// peuvent être corrigés, et je commence à travailler dessus très bientôt (vraiment).
Les liens flous n’ont pas de solution réaliste (et ouvriront la porte à ReDoS). Mais, comme je l’ai dit plusieurs fois, la valeur ajoutée de ce mode n’est pas évidente, et il est désactivé par défaut en raison de nombreux effets secondaires. Je l’ai fait uniquement parce que d’autres packages le proposaient.
1 « J'aime »
Je pense que la résolution du cas http(s):// apportera d’énormes avantages.
La grande majorité des gens copient simplement une URL depuis la barre d’adresse du navigateur, elle inclut certainement le protocole.
1 « J'aime »
En effet. Je ne connais pas de cas réels où des liens sans protocole peuvent être utiles.
C’est généralement pour des cas limites où les utilisateurs se souviennent d’un domaine et veulent simplement le taper. Habituellement, un chemin n’est pas impliqué, un paramètre de requête… presque jamais.
Par exemple :
\u003e Hé… as-tu regardé discourse.org
2 « J'aime »
IMO, forcer de tels utilisateurs à taper https:// pour de tels liens est plus simple que de lutter contre les effets secondaires du mode flou.
Voir aussi : Links broken with (at least) two underscores in URL