You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
A wikilink is detected. The iterator returns some wikilink text and the string range, which encompasses the whole link ([[some wikilink text]]).
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.
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.
The text was updated successfully, but these errors were encountered:
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:
The parse process for this note would proceed as such:
some wikilink text
and the string range, which encompasses the whole link ([[some wikilink text]]
).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.The text was updated successfully, but these errors were encountered: