-
Notifications
You must be signed in to change notification settings - Fork 18
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
Configurable link-style generation #103
Comments
Actually, since HTML generation doesn't happen until note.as_html(LinkStyle::Clean) This would be an API breaking change tho |
Great question, and something that definitely needs to be considered! However, firstly we need to establish the following: Seeing as you want clean links to all your internal pages, can we assume the option you want should only apply to wikilinks?
Excited to hear your thoughts! |
I think a pluggable interface to customize link generation is a very good idea! It would allow downstream projects to do what they wish with links without bloating mdzk with a ton of conditional logic. Do you have a roadmap for #77? I can take a swing at implementing it if you have a design in mind for the API |
@MatteoJoliveau check out #104! It's still a work in progress, but you should get an idea of how I'm imagining the API to be. Feel free to leave any suggestions there, if you'd like 😄 |
Hi, it's me again!
Currently
fn fix_link(dest: CowStr) -> CowStr
converts markdown links fromsomething/something.md
tosomething/something.html
. This makes it difficult to support clean URLs (aka/my/page
instead of/my/page.html
). In my case, I actually generate HTML files as independentindex.html
files in dedicated directories. For instance, this is the conversion my SSG performs:Proposed solution
Have the Vault accept an additional (optional) configuration flag that asks whether to generate clean URLs or not. Since the output of the actual HTML files is up to the caller, the only thing this flag does is change the behaviour of
fix_link()
. The flag can befalse
by default to keep the current behaviour as the default one.Currently, I worked around this by parsing the generated HTML and applying some heuristics based on the current note path, fixing relative links and cleaning up file extensions, but it's cumbersome (around 60 LOC of pretty inefficient string manipulation) and the built-in solution would be much cleaner and more efficient.
Alternatives I considered
One alternative would be to skip
Note::as_html
and implement Markdown parsing myself using pulldown-cmark. That could work, and I may have to do it anyway in the future for stuff like custom HTML nodes, but I still think this could be a useful feature for use-cases that do not require such fine-grained control over the parsed DOM.The text was updated successfully, but these errors were encountered: