Wenn ein Link mehr als einen Punkt hat, weiß der Komponist nicht, wie er damit nach dem zweiten Punkt umgehen soll. Wie dieser hier:
Bug oder Feature?
https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al.canine_pancreatitis-_review.pdf
Ich glaube, Sie haben die Hervorhebung verwendet, indem Sie canine_pancreatitis wie diesen Text geschrieben haben.
1 „Gefällt mir“
Die Kursivschrift ist auf den Unterstrich nach dem zweiten Punkt zurückzuführen. Wenn Sie den Link in < > einschließen, wird er meiner Meinung nach richtig angezeigt:
<https://www.sell.fi/sites/default/files/elainlaakarilehti/tieteelliset_artikkelit/kahkonen_t._et_al._canine_pancreatitis_-_review.pdf>
4 „Gefällt mir“
Jeden Tag etwas Neues. Ich wusste nicht, dass Unterstriche auch kursiv sind.
Also… es ist ein Feature, kein Bug 
1 „Gefällt mir“
Nun, die automatische Verknüpfung wird durch die mehreren Punkte im PDF-Link verwirrt und beginnt, die folgenden Unterstriche als Markdown zu lesen, was vielleicht nicht wünschenswert ist?
Aber die Escape-Zeichen <> sind eine gute Problemumgehung, wenn Sie sie benötigen. 
2 „Gefällt mir“
Es ist etwas, das @Vitaly verfolgt, es hängt wirklich davon ab, wie häufig diese Probleme sind. Wenn es 1 von einer Million Links ist, lohnt es sich nicht, den Linkifier zu verbessern, wenn es 1 von 10 ist, dann sicherlich.
4 „Gefällt mir“
Das kommt darauf an. Wenn wissenschaftliche Links und PDFs geteilt werden müssen, wie in meinem Forum, ist das sehr üblich und deckt fast jeden Link ab. Ansonsten nicht so oft, aber auch mehr als ein Punkt ist keine seltene Form.
Aus meiner Sicht – gibt es einen Grund, warum das Beginnen mit http:// oder https:// und das Beenden mit einem Leerzeichen nicht ausreicht, plus natürlich erlaubte Dateiformate?
Die Regeln sind komplex und entwickeln sich weiter.
Der Linkifier funktioniert auch ohne das https://-Präfix, was zusätzliche Komplexität hinzufügt.
Ich vermute, dass wir etwas tun könnten, um das Verhalten des Linkifiers für den Fall des https://-Präfixes zu lockern, aber das überlasse ich Vitaly.
1 „Gefällt mir“
Das ist irgendwie mein Punkt 
Nun, ich versuche, den Benutzern beizubringen, wie man < und > verwendet. Das größte UX-Problem hier ist, dass Discourse in vielen Fällen anders reagiert, als die Benutzer es erwarten. Aber das ist eine viel tiefere Sache, als nur zu versuchen, sich zu merken, wann Links funktionieren und wann nicht.
Das ergibt für mich Sinn. Ich denke, es wäre in Ordnung, nur Hostnamen ohne Pfad zu verlinken und für URLs mit einem Pfad http zu verlangen.
Ich habe einen Testfall aufgezeichnet, aber mit hoher Wahrscheinlichkeit handelt es sich um dasselbe auf Betonung basierende Problem wie zuvor.
Im Allgemeinen können alle Links mit dem Protokoll http(s):// behoben werden, und ich werde bald damit beginnen (wirklich).
Fuzzy-Links haben keine realistische Lösung (und öffnen die Tür für ReDoS). Aber wie ich schon oft gesagt habe, ist der Mehrwert dieses Modus nicht offensichtlich, und er ist standardmäßig deaktiviert, da er viele Nebenwirkungen hat. Ich habe ihn nur gemacht, weil andere Pakete ihn bereitgestellt haben.
1 „Gefällt mir“
Ich denke, die Lösung des Falls http(s):// wird enorme Vorteile bringen. Die überwiegende Mehrheit der Leute kopiert einfach eine URL aus der Adressleiste des Browsers, die sicherlich das Protokoll enthält.
1 „Gefällt mir“
In der Tat. Ich kenne keine realen Fälle, in denen Links ohne Protokoll nützlich sein können.
Dies ist normalerweise für Ausnahmefälle gedacht, in denen sich Benutzer an eine Domain erinnern und sie einfach eingeben möchten. Normalerweise ist kein Pfad beteiligt, ein Query-Parameter … fast nie.
Z.B.:
Hey… hast du dir discourse.org angesehen
2 „Gefällt mir“
IMO ist es für solche Benutzer einfacher, https:// für solche Links einzugeben, als gegen die Nebenwirkungen des Fuzzy-Modus zu kämpfen.