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.
Quoi qu’il en soit, je ne suis pas d’accord : je pense que dans (2)edit : le cas général de [texte](URL) (appelons-le (2a)), l’URL du lien devrait être réécrite de la même manière que (1). (Je suis d’accord que le comportement actuel consistant à réécrire le texte et non l’URL est complètement erroné.) Je prends la décision entre écrire (1) et (2a) en fonction de si je pense qu’il est utile ou distrayant que l’URL soit visible par le lecteur, et non en fonction d’une intention quant à savoir si le lien doit pointer vers la version du code telle qu’écrite ou telle qu’elle sera lue. Bien sûr, je suis conscient du problème des liens permanents, donc j’en crée moi-même un chaque fois que j’en ai besoin. Mais plus généralement, si un administrateur Discourse décide d’activer le bot de liens permanents, c’est probablement parce qu’il pense que la plupart de ses utilisateurs ne sont pas conscients du risque que les liens basés sur le nom de branche puissent se dégrader, et je ne pense pas que l’utilisation de la syntaxe de lien Markdown soit un signal suffisant qu’un utilisateur donné est conscient du problème mais souhaite se désengager de la réécriture de ce lien particulier.
Mais je pense que nous spéculons tous les deux ici. En tant qu’utilisateur avancé, je me soucie peu de la valeur par défaut tant que je peux la remplacer au besoin.
Oui, exactement. Actuellement, il n’y a aucun moyen de le remplacer. Écrire [url](url) (le texte du lien et l’URL sont exactement les mêmes) serait certainement un moyen de signaler au bot que ce lien ne doit pas être réécrit, car il n’y a aucune autre raison de l’écrire de cette façon.
Il y en a une si vous voulez donner à votre lien son propre titre plutôt que de le laisser être déduit de l’URL cible, c’est-à-dire [titre](url). Donner un titre au lien n’indiquerait aucune préférence pour la réécriture d’URL, donc je suis d’accord avec @mattmccutchen sur le fait que 1 et 2 devraient se comporter de manière cohérente pour la réécriture d’URL.
On pourrait soutenir que le titre correspondant exactement à l’URL est une indication qu’elle ne devrait pas être réécrite, mais que faire si un utilisateur veut fournir un titre et veut que l’URL ne soit pas réécrite ? Il doit y avoir une autre méthode pour spécifier cela.
Quelque chose qui vient à l’esprit serait un suffixe de titre similaire à la taille des images intégrées, bien que je ne sois pas sûr de la façon dont un utilisateur le découvrirait.
Une image intégrée peut être redimensionnée comme ceci : 
Ainsi, le plugin discourse-github pourrait (vraisemblablement) être fait pour rechercher quelque chose comme ceci : [titre|github-no-rewrite](url)
Ah, il n’était pas clair pour moi que votre (2) faisait référence uniquement au cas spécial où le texte et l’URL sont identiques. Ma déclaration concernait le cas général où le texte et l’URL peuvent être différents ; appelons cela (2a) maintenant.
Dans le cas (2), je suis d’accord qu’il est étrange de réécrire l’URL et non le texte, les laissant incohérents, mais il me semble qu’on pourrait tout aussi bien soutenir que si nous voulons éviter l’incohérence, le meilleur moyen d’y parvenir est de réécrire à la fois l’URL et le texte plutôt que ni l’un ni l’autre. Je ne trouve donc pas l’argument de traiter (2) comme un refus convaincant. Étant donné que nous devrions avoir un refus qui fonctionne pour (2a), je serais enclin à laisser les utilisateurs utiliser le même refus pour (2) et à ne pas compliquer la conception. (Je pense que c’était peut-être aussi l’idée de Simon Manning ?)
Je ne suis pas sûr de suivre correctement (ou si c’est possible), mais pourriez-vous utiliser l’échappement d’espace comme dans le lien Inline PDF Previews - #45 by Johani ? Ainsi, [ texte]( url) ne réécrirait ni le texte ni l’url, et tout le reste serait automatiquement modifié ?
Pas un test valide car la réécriture des permaliens GitHub est entièrement désactivée sur cette instance Discourse. (Je me demande ce que cela dit de cette fonctionnalité si elle est désactivée sur l’instance « officielle » )
)