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, discordo: acho que no (2)editar: o caso geral de [texto](URL) (chame isso de (2a)), o URL do link deve ser reescrito da mesma forma que (1). (Concordo que o comportamento atual de reescrever o texto e não o URL está completamente quebrado.) Eu tomo a decisão entre escrever (1) e (2a) com base se acho útil ou distrativo que o URL seja visível para o leitor, não com base em qualquer intenção sobre se o link deve apontar para a versão do código como escrita ou como lida. Claro, estou ciente do problema do link permanente, então eu mesmo crio um link permanente sempre que quero um. Mas, de forma mais geral, se um administrador do Discourse decidir habilitar o bot de link permanente, presumivelmente é porque eles acham que a maioria de seus usuários não está ciente do risco de que links baseados em nomes de branch possam se tornar obsoletos, e eu não acho que o uso da sintaxe de link Markdown seja um grande sinal de que um determinado usuário está ciente do problema, mas deseja optar por não ter esse link específico reescrito.
Mas acho que ambos estamos apenas especulando aqui. Como um usuário avançado, eu não me importo muito com o padrão, desde que eu possa substituí-lo conforme necessário.
Sim, exatamente. Atualmente não há como substituí-lo. Escrever [url](url) (o texto do link e o URL são exatamente os mesmos) definitivamente seria uma maneira de sinalizar ao bot que esse link não deve ser reescrito, porque não há outra razão para escrevê-lo dessa forma.
Existe se você quiser dar ao link seu próprio título em vez de tê-lo inferido do URL de destino, ou seja, [título](url). Dar um título ao link não indicaria nenhuma preferência por reescrita de URL, então concordo com @mattmccutchen que 1 e 2 devem se comportar de forma consistente para reescrita de URL.
Poderia haver um argumento para o título corresponder exatamente ao URL ser uma indicação de que ele não deve ser reescrito, mas e se um usuário quiser fornecer um título e quiser que o URL não seja reescrito? Precisa haver algum outro método para especificar isso.
Algo que me vem à mente seria um sufixo de título semelhante ao dimensionamento de imagem incorporada, embora eu não tenha certeza de como um usuário o descobriria.
Uma imagem incorporada pode ser dimensionada assim: 
Portanto, o plugin discourse-github poderia (presumivelmente) ser feito para procurar algo como isto: [título|github-no-rewrite](url)
Ah, não ficou claro para mim que o seu (2) se referia apenas ao caso especial em que o texto e o URL são os mesmos. Minha declaração era para o caso geral em que o texto e o URL podem não ser os mesmos; vamos chamar isso de (2a) agora.
No caso (2), concordo que é estranho reescrever o URL e não o texto, deixando-os inconsistentes, mas ISTM que se poderia argumentar igualmente que, se quisermos evitar a inconsistência, a melhor maneira de fazer isso é reescrever tanto o URL quanto o texto, em vez de nenhum deles. Portanto, não acho o argumento para tratar (2) como um opt-out convincente. Dado que devemos ter um opt-out que funcione para (2a), eu tenderia a apenas deixar os usuários usarem o mesmo opt-out para (2) e não complicar o design. (Acho que essa pode ter sido a ideia de Simon Manning também?)
Não tenho certeza se estou entendendo isso certo (ou se é possível), mas você poderia usar o escape de espaço como em Inline PDF Previews - #45 by Johani? Então [ texto]( url) não reescreveria nem o texto nem a url, e qualquer outra coisa seria alterada automaticamente?
Não é um teste válido porque a reescrita de permalink do GitHub está desativada inteiramente nesta instância do Discourse. (Fico me perguntando o que isso diz sobre esse recurso se ele está desativado na instância “oficial” )
)