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, no estoy de acuerdo: creo que en (2)edición: el caso general de [texto](URL) (llámalo (2a)), la URL del enlace debería reescribirse de la misma manera que (1). (Estoy de acuerdo en que el comportamiento actual de reescribir el texto y no la URL está completamente roto). Tomo la decisión entre escribir (1) y (2a) basándome en si creo que es útil o molesto que la URL sea visible para el lector, no basándome en ninguna intención sobre si el enlace debe apuntar a la versión del código tal como está escrita o tal como se lee. Por supuesto, soy consciente del problema de los enlaces permanentes, así que creo uno yo mismo siempre que quiero uno. Pero, en general, si un administrador de Discourse decide habilitar el bot de enlaces permanentes, presumiblemente es porque piensa que la mayoría de sus usuarios no son conscientes del riesgo de que los enlaces basados en nombres de rama puedan corromperse, y no creo que el uso de la sintaxis de enlaces Markdown sea una gran señal de que un usuario determinado es consciente del problema pero quiere excluirse de que ese enlace en particular sea reescrito.
Pero creo que ambos solo estamos especulando aquí. Como usuario avanzado, no me importa mucho cuál sea el valor predeterminado, siempre y cuando pueda anularlo según sea necesario.
Sí, exactamente. Actualmente no hay forma de anularlo. Escribir [url](url) (el texto del enlace y la URL son exactamente iguales) sin duda sería una forma de indicar al bot que ese enlace no debe ser reescrito, porque no hay otra razón para escribirlo de esa manera.
La hay si quieres darle al enlace tu propio título en lugar de que se infiera de la URL de destino, es decir, [título](url). Darle un título al enlace no indicaría ninguna preferencia por la reescritura de URL, así que estoy de acuerdo con @mattmccutchen en que 1 y 2 deberían comportarse de manera consistente para la reescritura de URL.
Podría argumentarse que el título que coincide exactamente con la URL es una indicación de que no debería reescribirse, pero ¿y si un usuario quiere proporcionar un título y quiere que la URL no se reescriba? Debe haber algún otro método para especificar eso.
Algo que me viene a la mente sería un sufijo de título similar al tamaño de las imágenes incrustadas, aunque no estoy seguro de cómo lo descubriría un usuario.
Una imagen incrustada se puede dimensionar así: 
Por lo tanto, el plugin discourse-github podría (presumiblemente) hacerse para buscar algo como esto: [título|github-no-rewrite](url)
Ah, no me quedó claro que tu (2) se refería solo al caso especial en el que el texto y la URL son los mismos. Mi declaración era para el caso general en el que el texto y la URL pueden no ser los mismos; llamémoslo (2a) ahora.
En el caso (2), estoy de acuerdo en que es extraño reescribir la URL y no el texto, dejándolos inconsistentes, pero ISTM uno podría argumentar igualmente que si queremos evitar la inconsistencia, la mejor manera de hacerlo es reescribir tanto la URL como el texto en lugar de ninguno. Por lo tanto, no encuentro convincente el argumento para tratar (2) como una exclusión. Dado que deberíamos tener una exclusión que funcione para (2a), me inclinaría a simplemente dejar que los usuarios usen la misma exclusión para (2) y no complicar el diseño. (¿Creo que esta también fue la idea de Simon Manning?)
No estoy seguro de seguir esto correctamente (o si es posible), pero ¿podrías usar el escape de espacio como en el Inline PDF Previews - #45 by Johani? Entonces [ texto]( url) no reescribiría ni el texto ni la url, ¿y todo lo demás se cambiaría automáticamente?
No es una prueba válida porque la reescritura de permalinks de GitHub está completamente deshabilitada en esta instancia de Discourse. (Me pregunto qué dice eso sobre esta función si está deshabilitada en la instancia “oficial” )
)