Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add alternative to relref #135

Open
toby63 opened this issue Jan 29, 2021 · 4 comments
Open

Add alternative to relref #135

toby63 opened this issue Jan 29, 2021 · 4 comments

Comments

@toby63
Copy link
Contributor

toby63 commented Jan 29, 2021

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
Copy link
Member

Kissaki commented Feb 16, 2021

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
Copy link
Contributor Author

toby63 commented Feb 17, 2021

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
Copy link
Member

Kissaki commented Feb 18, 2021

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
Copy link
Contributor Author

toby63 commented Feb 18, 2021

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants