Se um link tiver mais de um ponto, o composer não saberá como lidar com ele após o segundo ponto. Como este:\n\nhttps://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al._canine_pancreatitis_-_review.pdf\n\nBug ou recurso?
https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf
Acho que você usou o efeito de ênfase escrevendo canine_pancreatitis. como este texto.
1 curtida
As itálicas são por causa do sublinhado após o segundo ponto. Se você envolver o link em < > acho que ele é exibido corretamente:
<https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al._canine_pancreatitis_-_review.pdf>
4 curtidas
Todo dia algo novo. Eu não sabia que underscores também deixavam em itálico.
Então… é um recurso, não um bug 
1 curtida
Bem, a auto-vinculação está confusa pelos múltiplos pontos no link do PDF, e começa a ler os underscores seguintes como markdown, o que pode não ser desejável?
Mas o escape \u003c\\u003e é uma boa solução alternativa, se você precisar. 
2 curtidas
É algo que o @Vitaly está acompanhando, realmente depende de quão comuns são esses problemas. Se for 1 em um milhão de links, não vale a pena melhorar o linkificador, se for 1 em 10, certamente vale.
4 curtidas
Depende. Se houver necessidade de compartilhar links científicos e PDFs, como no meu fórum, é muito comum cobrir quase todos os links. Caso contrário, não tão frequentemente, mas mais de um ponto não é uma forma tão rara.
Do meu ponto de vista — existe algum motivo pelo qual iniciar http:// ou https:// e terminar com um espaço não é suficiente, além dos formulários de arquivo permitidos, é claro?
As regras são complexas e estão em evolução.
O linkifier também funciona sem o prefixo https:// para adicionar complexidade extra.
Suspeito que poderíamos fazer algo para relaxar o comportamento dos linkifiers para o caso do prefixo https://, mas deixarei Vitaly opinar.
1 curtida
De alguma forma, esse é o meu ponto 
Bem, estou tentando ensinar os usuários a usar < e >. A maior questão de UX aqui é que o Discourse começa a agir em muitos casos de forma muito diferente do que os usuários esperam. Mas isso é algo muito mais profundo do que apenas tentar lembrar quando os links funcionam e quando não funcionam.
Isso faz sentido para mim. Acho que pode ser bom apenas linkificar nomes de host puros e exigir que URLs com um caminho tenham http.
Gravei um caso de teste, mas com alta probabilidade é o mesmo problema baseado em ênfase de antes.
Em geral, todos os links com protocolo http(s):// podem ser corrigidos, e eu começo a trabalhar nisso muito em breve (de verdade).
Links imprecisos não têm solução realista (e abrirão portas para ReDoS). Mas, como eu disse muitas vezes, o valor agregado desse modo não é óbvio, e ele está desativado por padrão por causa de muitos efeitos colaterais. Eu só fiz isso porque outros pacotes o forneciam.
1 curtida
Acredito que resolver o caso http(s):// trará enormes benefícios. A vasta maioria das pessoas está apenas copiando uma URL da barra de endereços do navegador, que certamente inclui o protocolo.
1 curtida
De fato. Não conheço casos reais em que links sem protocolo possam ser úteis.
Geralmente é para casos extremos em que os usuários se lembram de um domínio e apenas querem digitá-lo. Geralmente, um caminho não está envolvido, um parâmetro de consulta… quase nunca.
Ex:
\u003e Ei… você já viu discourse.org
2 curtidas
No IMO forçar tais usuários a digitar https:// para tais links é mais simples do que lutar contra os efeitos colaterais do modo difuso.
Veja também: Links broken with (at least) two underscores in URL