Si un enlace tiene más de un punto, el compositor no sabe cómo manejarlo después del segundo punto. Como este:
¿Error o característica?
https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf
Creo que usaste el efecto de énfasis al escribir canine_pancreatitis. como este texto.
1 me gusta
Las cursivas se deben al guion bajo después del segundo punto. Si envuelves el enlace en < > creo que se muestra correctamente:
<https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al._canine_pancreatitis_-_review.pdf>
4 Me gusta
Cada día algo nuevo. No sabía que los guiones bajos también ponían en cursiva.
Así que… es una característica, no un error 
1 me gusta
Bueno, el enlace automático se confunde con los múltiples puntos en el enlace del pdf y comienza a leer los guiones bajos siguientes como markdown, lo cual podría no ser deseable.
Pero el escape \u003c\\u003e es una buena solución si lo necesitas. 
2 Me gusta
Es algo que @Vitaly está rastreando, realmente depende de cuán comunes sean estos problemas. Si es 1 de cada millón de enlaces, no vale la pena mejorar el enlazador, si es 1 de cada 10, ciertamente lo es.
4 Me gusta
Depende. Si hay necesidad de compartir enlaces y PDFs científicos, como en mi foro, es muy común cubrir casi todos los enlaces. De lo contrario, no tan a menudo, pero tampoco es raro ver más de un punto.
Desde mi punto de vista, ¿hay alguna razón por la que no sea suficiente empezar con http:// o https:// y terminar en un espacio, además de los formatos de archivo permitidos, por supuesto?
Las reglas son complejas y están en constante evolución.
El “linkifier” también funciona sin el prefijo https:// para añadir complejidad adicional.
Sospecho que podríamos hacer algo para relajar el comportamiento del “linkifier” en el caso del prefijo https://, pero dejaremos que Vitaly opine.
1 me gusta
Ese es, de alguna manera, mi punto 
Bueno, estoy tratando de enseñar a los usuarios a usar < y >. El mayor problema de UX aquí es que Discourse comienza a actuar en muchos casos de manera muy diferente a la que los usuarios esperan. Pero eso es algo mucho más profundo que simplemente tratar de recordar cuándo funcionan los enlaces y cuándo no.
Eso tiene sentido para mí. Creo que estaría bien enlazar solo nombres de host simples y requerir que las URL con una ruta tengan http.
He grabado un caso de prueba, pero con alta probabilidad es el mismo problema basado en énfasis que antes.
En general, todos los enlaces con el protocolo http(s):// se pueden arreglar, y empezaré a trabajar en esto muy pronto (de verdad).
Los enlaces difusos no tienen una solución realista (y abrirán la puerta a ReDoS). Pero, como he dicho muchas veces, el valor añadido de este modo no es obvio, y está deshabilitado por defecto debido a muchos efectos secundarios. Solo lo hice porque otros paquetes lo proporcionaban.
1 me gusta
Creo que resolver el caso http(s):// dará enormes resultados.
La gran mayoría de las personas simplemente copian una URL de la barra de direcciones del navegador, ciertamente incluye el protocolo.
1 me gusta
De hecho. No conozco casos reales en los que los enlaces sin protocolo puedan ser útiles.
Normalmente es para casos extremos en los que los usuarios recuerdan un dominio y solo quieren escribirlo. Normalmente no se incluye una ruta, un parámetro de consulta… casi nunca.
Por ejemplo:
Oye… ¿has mirado discourse.org
2 Me gusta
IMO forzar a dichos usuarios a escribir https:// para tales enlaces es más simple que luchar contra los efectos secundarios del modo difuso.
Ver también: Links broken with (at least) two underscores in URL