Add the delimiter to the context into the render-passthrough

[relma2]

Reopening #12803 . @bep wanted a use case for that feature, and one of them is... Obsidian. Their internal links, in-vault images, comments, and others don't play nice with Hugo. For example:

A wikilink has the form [[Linkpage#Heading|DisplayText]] OR [[Linkpage^taggedLine|DisplayText]] where Heading, taggedLine, and DisplayText are optional. Allow double square bracket delimiters to be recognized to be processed as a different type of delimiter and handled by passthrough.

Comments are of the form %% This is a comment %%. This render hook would simply be empty.

People have cobbled together janky scripts to convert an Obsidian flavored markdown into SSG markdown before passing into Hugo, but I would like a pure Hugo solution so then we can just steal a set of Obsidian render hooks.

[bep]

[[Linkpage#Heading|DisplayText]] OR [[Linkpage^taggedLine|DisplayText]] where Heading, taggedLine, and DisplayText are optional. Allow double square bracket delimiters to be recognized to be processed as a different type of delimiter and handled by passthrough.

I don't understand how the above would be rendered in a render hook? Just as plain text?

[relma2]

Fair, it's on me for assuming you have used Obsidian before.

According to their documentation on links internal "wikilinks" come in a few forms

• Standalone: [[Filename]]
• As Alias: [[MyAlias]] ⟵ where "MyAlias" is listed as an alias property in the YAML frontmatter
• To heading within file: [[Filename#Headingname]]
• To labelled block in a note: [[Filename#^37066f]] ⟵ you can define a custom label or Obsidian can make a random one
• With display text: [[Filename|Display Text]] is equal to <a href="/path/to/filename.html"> Display Text </a>

And so a render hook would sort of... match on the double square bracket delimeter as a different type of content than, say, a math-block delimiter. Like there would be a partial named layouts/_markup/render-passthrough-math.html and layouts/_markup/render-passthrough-wikilink.html... and then the goldmark part of the config.toml would look like this:

# markup.goldmark.extensions.passthrough.enableTrue...
[...kinds]:
  math:
    type = block
    delim = [['\[', '\]'], ['$$', '$$']]
    path = 'path/to/layouts/_markup/render-passthrough-math.html'
  mathinline:
    type = inline
    delim = ['$', '$']
    path = '.../...mathinline.html'
  wikilink:
    type = inline
    delim = ['[[', ']]']
    path = '.../layouts/_markup/render-passthrough-wikilink.html'

And then the wikilink passthrough would just do regexp handling to resolve the link differently than the standard [DisplayText](https://example.com)

...annnd now I'm realizing how defining different types of passthroughs would be a massively scope-creeped feature.

[bep]

Fair, it's on me for assuming you have used Obsidian before.

I have. And I also read https://github.com/fingon/tagged-obsidian-to-hugo where it says:

Local links resolve relative to the source note first. If that misses, the exporter falls back to searching the whole vault by note name or attachment basename. Links to exported notes become relative Hugo markdown links such as ../other-note/

So, I don't see how one could resolve these links in a hook template without having more information about the Obsidian structure.

...annnd now I'm realizing how defining different types of passthroughs would be a massively scope-creeped feature.

It's not that scope-creeping, and given your examples is harder than they should be. We curently only support 1 config entry for passthrough, but allowing muliple sounds reasonable, if we find a valid use for it.