Se un link ha più di un punto, il composer non sa come gestirlo dopo il secondo punto. Come questo:
Bug o funzionalità?
https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf
Penso che tu abbia usato l’effetto enfasi scrivendo canine_pancreatitis. come questo testo.
1 Mi Piace
Il corsivo è dovuto al trattino basso dopo il secondo punto. Se racchiudi il link tra \u003c \\u003e penso che venga visualizzato correttamente:
\u003chttps://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf\u003e
\u003chttps://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf\u003e
4 Mi Piace
Ogni giorno qualcosa di nuovo. Non sapevo che anche i trattini bassi facessero il corsivo.
Quindi… è una funzionalità, non un bug 
1 Mi Piace
Beh, il collegamento automatico viene confuso dai periodi multipli nel link del pdf, e inizia a leggere i successivi underscore come markdown, il che potrebbe non essere desiderabile?
Ma l’escape \u003c\\u003e è un buon workaround se ne hai bisogno. 
2 Mi Piace
È qualcosa che @Vitaly sta monitorando, dipende molto da quanto siano comuni questi problemi. Se si tratta di 1 link su un milione non vale la pena migliorare il linkifier, se invece è 1 su 10 sicuramente sì.
4 Mi Piace
Dipende. Se c’è la necessità di condividere link scientifici e PDF, come sul mio forum, è molto comune coprire quasi ogni link. Altrimenti, non così spesso, ma anche la forma con più di un punto non è rara.
Dal mio punto di vista, c’è qualche motivo per cui iniziare con http:// o https:// e finire con uno spazio non è sufficiente, oltre ai formati di file consentiti, ovviamente?
Le regole sono complesse e in evoluzione.
Il linkifier funziona anche senza il prefisso https:// per aggiungere ulteriore complessità.
Sospetto che potremmo fare qualcosa per rilassare il comportamento dei linkifier per il caso del prefisso https://, ma lascerò che Vitaly dica la sua.
1 Mi Piace
Questo è in qualche modo il mio punto 
Bene, sto cercando di insegnare agli utenti a usare < e >. Il più grande problema “UX-ish” qui è che Discourse inizia ad agire in molti casi in modo troppo diverso da quanto gli utenti si aspettano. Ma questa è una cosa molto più profonda che cercare solo di ricordare quando i link funzionano e quando no.
Questo ha senso per me. Penso che potrebbe andare bene linkificare solo i nomi host nudi e richiedere che gli URL con un percorso abbiano http.
Ho registrato un caso di test ma con alta probabilità è lo stesso problema basato sull’enfasi di prima.
In generale, tutti i link con protocollo http(s):// possono essere corretti e inizierò a lavorarci molto presto (davvero).
I link fuzzy non hanno una soluzione realistica (e apriranno la porta a ReDoS). Ma, come ho detto molte volte, il valore aggiunto di questa modalità non è ovvio ed è disabilitato per impostazione predefinita a causa di molti effetti collaterali. L’ho fatto solo perché altri pacchetti lo fornivano.
1 Mi Piace
Penso che risolvere il caso http(s):// darà un’enorme spinta.
La stragrande maggioranza delle persone sta semplicemente copiando un URL dalla barra degli indirizzi del browser, include certamente il protocollo.
1 Mi Piace
Infatti. Non conosco casi reali in cui i link senza protocollo possano essere utili.
Di solito è per casi limite in cui gli utenti ricordano un dominio e vogliono semplicemente digitarlo. Di solito non è coinvolto un percorso, un parametro di query… quasi mai.
Ad esempio:
Ehi… hai controllato discourse.org
2 Mi Piace
IMO forzare tali utenti a digitare https:// per tali collegamenti è più semplice, che combattere gli effetti collaterali della modalità fuzzy.