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

Render hooks for custom formatting of links #19

Open
mntn-xyz opened this issue Aug 27, 2021 · 4 comments
Open

Render hooks for custom formatting of links #19

mntn-xyz opened this issue Aug 27, 2021 · 4 comments
Labels
enhancement New feature or request gmnhg Issue related to cmd/gmnhg major Requires a major refactoring or rewrite renderer Issue related to the Gemtext renderer

Comments

@mntn-xyz
Copy link
Contributor

mntn-xyz commented Aug 27, 2021

This may not be possible without ugly hacks, but I wanted to generate some discussion around it since it would be a useful feature.

There are some sites that publish on both Gemini and the web. If I am linking to such a blog from the web, I'll probably use the web link. If I'm linking from Gemini, I probably want to use the Gemini link. I wonder if there's any way to provide both links in such a way that the Hugo renderer will output the HTTP(S) link while gmnhg will output the Gemini link.

I looked at attributes, but they can't yet be applied to links in Commonmark (goldmark) or blackfriday (gomarkdown), although there has been discussion about it: see commonmark/commonmark-spec#105 and russross/blackfriday#181

The one thing that is supported by both Commonmark and blackfriday, and appears to be supported in gomarkdown, is the "title" attribute. I suppose that could be abused to hold an alternate Gemini link, and on the Hugo side a custom link template (layouts/_default/_markup/render-link.html) could be used to ignore that attribute entirely. But this feels wrong.

Here's what it would look like:

[My wish-list for the next YAML](https://drewdevault.com/2021/07/28/The-next-YAML.html "gemini://drewdevault.com/2021/07/28/The-next-YAML.gmi")

I don't think that the markup looks so bad, it's just that the abuse of the title attribute feels dirty. And of course there must be someone out there who uses the title attribute for legitimate purposes.

Any thoughts on a better approach for this? Or is this best shelved for some future date when link attributes are available?

@tdemin
Copy link
Owner

tdemin commented Aug 28, 2021

Can't you already do that using the schemaless links (like //personal.tld/document)? I haven't looked up much into how they implement that in clients / URI parsers, but it used to be what you'd usually do to include page resources in HTML pages that would automagically use the scheme the original HTML document was requested with (the browser would autosubstitute http:// / https:// instead of //), useful back in 10-s where complete HTTPS adoption was hard to achieve.

@tdemin tdemin added the question Further information is requested label Aug 28, 2021
@mntn-xyz
Copy link
Contributor Author

That only works if the site uses the same URLs for both protocols, which unfortunately is not always the case. (Although in my opinion, multi-protocol sites should try to do this. It's sort of an extension of the "cool URLs don't change" philosophy.)

For example, in the example I gave above, the URL is the same except for the ".html" and ".gmi" at the end. So swapping protocols wouldn't work.

I also came across another example the other day: https://alexschroeder.ch/wiki/2021-08-04_Swiss_privacy_law_and_mail_providers on HTTPS vs gemini://alexschroeder.ch/page/2021-08-04_Swiss_privacy_law_and_mail_providers on Gemini. The author was kind enough to do a redirect for the Gemini URLs, so if you go to gemini://alexschroeder.ch/wiki/2021-08-04_Swiss_privacy_law_and_mail_providers then it sends you to the right place.

@tdemin
Copy link
Owner

tdemin commented Aug 29, 2021

To be honest, I really think having the server operator enable something like this nginx directive (the closest I can think of) for their Gemini server software would really be the best solution:

server {
    ...
    location ^~ /page/ {
        try_files $uri.gmi =404;
    }
}

Although this is inevitably going to be a problem at some point when we'll want to add "next"/"prev" cross-references between posts, because we'll have to either somehow canonicalize URIs with gmnhg itself, or have the user do that in the template.

@mntn-xyz
Copy link
Contributor Author

mntn-xyz commented Aug 29, 2021

I've been thinking about it more, and I wonder if gmnhg could eventually have something like Hugo's Markdown render hooks: https://gohugo.io/getting-started/configuration-markup#markdown-render-hooks

This would allow each site to override the rendering defaults for certain types of content. So if someone wanted to grab the link "title" and use that as the URL, they could implement it themselves in a template and drop it into the proper folder under /gmnhg. There's probably some other good uses for this that I'm not thinking of right now.

Edit: Hugo also allows users to override headings, and I could see this being useful in gmnhg if someone wanted to change how H4-H6 were presented, for example.

@mntn-xyz mntn-xyz changed the title Links that automatically use the appropriate protocol Render hooks for custom formatting of links Sep 4, 2021
@tdemin tdemin added enhancement New feature or request gmnhg Issue related to cmd/gmnhg major Requires a major refactoring or rewrite renderer Issue related to the Gemtext renderer and removed question Further information is requested labels Sep 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request gmnhg Issue related to cmd/gmnhg major Requires a major refactoring or rewrite renderer Issue related to the Gemtext renderer
Projects
None yet
Development

No branches or pull requests

2 participants