mdzk-rs / mdzk

General-purpose interface to connected notes

Home Page:https://mdzk.app

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Wikilink handlers

kmaasrud opened this issue · comments

Wikilinks are key to how mdzk functions. In essence, they are simply text surrounded by a pair of square brackets on each side - line terminators not allowed. As such, modifying this text to provide new functionality should be trivial to implement and would allow a rich extensibility to mdzk.


I propose a link handler workflow. Each identified wikilink is passed through a selection of optional link handlers, to produce a string (generally, this should be Markdown or HTML.) Given the following file:

# This is the header of the file

This is the content. It contains a [[some wiklink text]].

The parse process for this note would proceed as such:

  1. A wikilink is detected. The iterator returns some wikilink text and the string range, which encompasses the whole link ([[some wikilink text]]).
  2. Each link handler is handed a reference to the wikilink text and some context. This context might contain a (mutable?) reference to the note containing the wiklink, a reference to the note it links to (if any), etc.
    • The reference to the wikilink text might either be a mutable reference or just a regular string. In the former case, each link handler would mutate the string. In the latter, each link handler would return a new string. I'm leaning towards the former, for performance reasons.
  3. After going through all the link handlers, we end up with a new string, which in most cases is something in CommonMark - likely a link. We then simply replace the original range with this new string, to finish the process.

Akin to mdBook, the API for this would simply be an WikilinkHandler trait that any crate using the mdzk lib would be able to implement and apply. Taking this a step further, I can imagine mdzk being able to both output link data for each note and building a vault by parsing it's own JSON, such that external preprocessors can be created.

Pushing this forward to the 1.0.0 release, since this would be a breaking API change.