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

Wikilink handlers #77

Open
kmaasrud opened this issue Mar 27, 2022 · 1 comment
Open

Wikilink handlers #77

kmaasrud opened this issue Mar 27, 2022 · 1 comment
Labels
enhancement New feature or request
Milestone

Comments

@kmaasrud
Copy link
Member

kmaasrud commented Mar 27, 2022

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.

@kmaasrud kmaasrud added the enhancement New feature or request label Mar 27, 2022
@kmaasrud kmaasrud added this to the 1.0.0 milestone Mar 27, 2022
@kmaasrud kmaasrud pinned this issue Mar 28, 2022
@kmaasrud kmaasrud modified the milestones: 1.0.0, 1.1.0 Apr 11, 2022
@kmaasrud kmaasrud unpinned this issue May 12, 2022
@kmaasrud kmaasrud changed the title Internal link preprocessors Wikilink handlers Aug 26, 2022
@kmaasrud kmaasrud modified the milestones: 1.1.0, 1.0.0 Aug 26, 2022
@kmaasrud
Copy link
Member Author

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

@kmaasrud kmaasrud linked a pull request Aug 30, 2022 that will close this issue
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant