About a year ago, I made a post on GitHub’s Discourse instance that included a bunch of URLs of the form “https://github.com/OWNER/REPO/tree/BRANCH/path” in order to discuss how GitHub.com processes such URLs. My post promptly received a system-generated edit with the message “Github link was replaced by a permanent link”, which appears to be coming from the discourse-github plugin. While replacing the branch name with a permanent link to the current commit ID may be a useful feature in the common case of a post citing particular code, in the special case of discussing GitHub URL processing, the edit destroyed the meaning of my post. I was lucky enough to notice the bot edit right away, and after several rounds of fighting with the bot, I eventually found a workaround of adding a <span> tag to prevent the bot’s pattern from matching, like this:
But other authors might not notice the bot edit and might be left with a post that would confuse readers.
What is the best solution to avoid undesired GitHub permanent link edits to a particular post? In general, I feel like it’s wrong for bots to make automatic edits that risk ruining a post. It would be safer to (1) ask the author when a post is saved whether the links should be edited or (2) have the bot add a permanent link without removing the original link. (I seem to recall seeing some bots on other web sites, maybe Reddit, that add information without deleting the existing information.) If the Discourse maintainers consider those options too ugly or too much work to accommodate a rare use case, some other options might be to (3) show a notice after the post is saved with a link to information about how the author can avoid the edits if needed, either as (a) a dedicated banner in the UI or (b) just a line of text added by the bot to the end of the post.
I’m not sure what would be the most reasonable design for the author to opt out of the edits. The discourse-github plugin’s site-wide exclusion settings based on the link target don’t seem well-suited for this purpose. Perhaps my current workaround with the <span> tag is adequate. Even if no change is made to Discourse, I hope this post will make the workaround easier to discover for authors who do notice the problem.
Note: I previously raised this issue on GitHub’s forum because I assumed the “permanent link” bot was specific to GitHub’s instance, but a commenter there clued me in that it is a general Discourse feature, so I’m raising the issue here.
I think this is a good feature, because people often paste links to master and these almost always grow outdated over time. Still, it should be possible to intentionally paste a link to a branch as there are many valid reasons to do this. Also generally this feature seems a bit broken, it rewrites things it shouldn’t and doesn’t parse things that it probably should.
Here are some examples that could be used as test cases to fix it:
URL enclosed in backquotes. This is not a link and should not be rewritten, but it is: https://github.com/ClassicPress/subdomain-static/blob/master/forums-enhancements.js
URL in a triple-backquoted code block. This is not a link and should not be rewritten, but it is:
I think only (1) above should be rewritten. This would make the behavior more predictable, and only rewrite “plain” links. Links where a specific markdown structure has been used (can be thought of as a way to express a specific intention) should be left alone.
FWIW, ich stimme nicht zu: Ich denke, im allgemeinen Fall von [text](URL) (nennen wir es (2a)), sollte die Link-URL genauso umgeschrieben werden wie (1). (Ich stimme zu, dass das aktuelle Verhalten, den Text und nicht die URL umzuschreiben, völlig fehlerhaft ist.) Ich entscheide zwischen dem Schreiben von (1) und (2a) danach, ob ich es für nützlich oder ablenkend halte, dass die URL für den Leser sichtbar ist, nicht basierend auf einer Absicht, ob der Link auf die Version des Codes zum Zeitpunkt des Schreibens oder zum Zeitpunkt des Lesens zeigen soll. Natürlich bin ich mir des Permanent-Link-Problems bewusst, daher erstelle ich selbst einen Permanent-Link, wann immer ich einen möchte. Aber allgemeiner gesagt, wenn ein Discourse-Administrator beschließt, den Permanent-Link-Bot zu aktivieren, dann wahrscheinlich, weil er denkt, dass die meisten seiner Benutzer sich des Risikos nicht bewusst sind, dass Branch-Name-basierte Links verrotten können, und ich glaube nicht, dass die Verwendung der Markdown-Link-Syntax ein großes Signal dafür ist, dass ein bestimmter Benutzer sich des Problems bewusst ist, aber von dieser speziellen Link-Umschreibung absehen möchte.
Aber ich denke, wir spekulieren hier beide nur. Als fortgeschrittener Benutzer ist mir die Standardeinstellung egal, solange ich sie bei Bedarf überschreiben kann.
Ja, genau. Derzeit gibt es keine Möglichkeit, dies zu überschreiben. Das Schreiben von [url](url) (Linktext und URL sind exakt gleich) wäre definitiv eine Möglichkeit, dem Bot zu signalisieren, dass dieser Link nicht neu geschrieben werden sollte, da es keinen anderen Grund gibt, ihn auf diese Weise zu schreiben.
Das ist der Fall, wenn Sie dem Link einen eigenen Titel geben möchten, anstatt ihn aus der Ziel-URL abzuleiten, d. h. [Titel](URL). Dem Link einen Titel zu geben, würde keine Präferenz für das Umschreiben von URLs anzeigen, daher stimme ich @mattmccutchen zu, dass 1 und 2 sich beim Umschreiben von URLs konsistent verhalten sollten.
Es könnte argumentiert werden, dass der Titel, der genau mit der URL übereinstimmt, ein Hinweis darauf ist, dass er nicht umgeschrieben werden sollte, aber was ist, wenn ein Benutzer einen Titel angeben möchte und möchte, dass die URL nicht umgeschrieben wird? Dafür muss es eine andere Methode geben.
Mir fällt ein Suffix für den Titel ein, ähnlich wie bei der Größenänderung von eingebetteten Bildern, obwohl ich nicht sicher bin, wie ein Benutzer das entdecken würde.
Ein eingebettetes Bild kann wie folgt dimensioniert werden: 
Daher könnte das discourse-github-Plugin (vermutlich) so etwas suchen: [Titel|github-no-rewrite](URL)
Ah, es war mir nicht klar, dass sich Ihr (2) nur auf den Sonderfall bezog, bei dem Text und URL gleich sind. Meine Aussage galt dem allgemeinen Fall, bei dem Text und URL nicht gleich sein können; nennen wir das jetzt (2a).
In Fall (2) stimme ich zu, dass es seltsam ist, die URL und nicht den Text neu zu schreiben, wodurch sie inkonsistent bleiben, aber meiner Meinung nach könnte man genauso gut argumentieren, dass, wenn wir die Inkonsistenz vermeiden wollen, der beste Weg darin besteht, sowohl die URL als auch den Text neu zu schreiben und nicht beide. Daher finde ich das Argument, (2) als Opt-out zu behandeln, nicht überzeugend. Da wir einen Opt-out haben sollten, der für (2a) funktioniert, würde ich dazu neigen, Benutzer einfach denselben Opt-out für (2) verwenden zu lassen und das Design nicht zu verkomplizieren. (Ich glaube, das war auch Simons Mannings Idee?)
Ich bin mir nicht sicher, ob ich das richtig verstehe (oder ob es möglich ist), aber könnten Sie die Leerzeichen-Maskierung wie in Inline PDF Previews - #45 by Johani verwenden? Dann würde [ text]( url) weder den Text noch die URL umschreiben, und alles andere würde automatisch geändert werden?
Kein gültiger Test, da das Rewriting von GitHub-Permalinks auf dieser Discourse-Instanz vollständig deaktiviert ist. (Ich frage mich, was das über diese Funktion aussagt, wenn sie auf der „offiziellen“ Instanz deaktiviert ist )
)