Add alternative to relref

[toby63]

relref is quite long and complicated to write, for example:
[Report a vulnerability]({{< relref "security#reporting-a-vulnerability" >}})
{{< wiki "3rd Party Applications" "already existing one" />}

Sadly upstream hugo does not seem to implement an alternative by themselves: gohugoio/hugo#3606

But I found two potential alternatives (but I don't know if they work correctly (as I intend it)):

1. https://github.com/13rac1/goldmark-wikilink
   Would be simply: [[pagename]]

   It seems additions are planned, for:

   • sections: [[pagename#category]]
   • custom naming: [[pagename|displayed text]

2. https://github.com/bep/portable-hugo-links/
   I have to admit that I am not sure this works as I understand it, but it seems this is natively possible with newer versions of hugo 🤔. So no extensions needed.

[Kissaki]

Can you please provide an example of how those would look, and if it is not obvious how that would be better?

Also, what technical requirements and additional complexity does this introduce? (Disadvantages)

Without having deep-dove, my stomach tells me introducing additional Hugo extensions seems like a bad idea when it already provides the linking functionality.

For context and possibly a foreseeable upstream conclusion, what does the linked Hugo ticket say about state, plan, consensus or opinions outside and inside of the Hugo team? The ticket is still open, so I presume the request was not dismissed.

[toby63]

Note: The following mainly refers to alternative one (the goldmark-wikilink extension).

Can you please provide an example of how those would look, and if it is not obvious how that would be better?

1. I have already provided code examples.
2. I don't know how it looks on a webpage, because I have not tried it out yet.
   This shows the example code transition on Github.
3. It is better, because it is shorter than relrefs and wiki tags.

Also, what technical requirements and additional complexity does this introduce? (Disadvantages)

None that I know of, I would need to test it to be sure (which I might do in some time).
It is an extension to goldmark and installed via go.

Without having deep-dove, my stomach tells me introducing additional Hugo extensions seems like a bad idea when it already provides the linking functionality.

🤔 Afaik this does not replace or disable anything, so I don't really see any danger.
But still one risk is that these extensions become outdated, if the developers don't support them anymore.

For context and possibly a foreseeable upstream conclusion, what does the linked Hugo ticket say about state, plan, consensus or opinions outside and inside of the Hugo team? The ticket is still open, so I presume the request was not dismissed.

Well most comments from the team are quite old (2018), but they seemed interested and not against it.
But seeing that nothing happened since then, I think it is stale and forgotten.

Still one team member suggested render hooks instead (gohugoio/hugo#3606 (comment)), which is alternative 2 from above and which is implemented natively into hugo it seems.
But I don't understand yet how that works exactly.

[Kissaki]

Interesting. The render hooks seem to be layout/_default files which replace the default behavior.

https://github.com/bep/portable-hugo-links/tree/master/layouts/_default/_markup

So this would be a native solution, but something we would have to maintain ourselves, and the complexity and (probably marginal) runtime increase would be the disadvantages.

It seems like they could be viable. It would need an adequate proposition and description of what we do.

[toby63]

Interesting indeed.
Official documentation: https://gohugo.io/getting-started/configuration-markup/#markdown-render-hooks

Interesting bits:

You can also create type/section specific hooks in layouts/[type/section]/_markup, e.g.: layouts/blog/_markup. (new in v0.71.0)