The Case for Non-Location Based WikiLinks
A few days ago while reading older posts about feature requests and bugs on WikiLinks I came across Fletcher’s reasoning for not implementing a refactor to automatically rename links and/or file names (foreshadowing: not what this post is going to be about). I liked it so much that it made me want to make the filesystem a first class citizen for my notes. A thought kept developing in the background in my head for a few days though and I think I found out what it is: [[WikiLink]] shouldn’tbe a syntactic sugar for [Markdown links](url).
A WikiLink is a link to a concept, not to specific location on disk – like Markdown links are. WikiLink being a concept of nvUltra, and not part of MultiMarkdown, lends nicely to this distinction. The app can help with forming connections between concepts and WikiLink could be the explicit tool for it, the tool where the user has control and is making the connection – the Connections button would be the implicit/automatic tool.
Having these two ways to link would also add some nice flexibility if one wants a location-link use markdown syntax, if it is a link to concept or a lenient-link (I’m not sure what to call these) then they can use WikiLink syntax.
The resolution of WikiLink could work like this. Given the following open folder in nvUltra:
- Coffee Notebook
- Attachments
- Brew diagram.png
- Home.md
- Best Coffee Brew.md
- Coffee Roasters
- Neighborhood Cafe.md
- Attachments
In `Home.md`:
# Coffee Home #  // 404 - Not Found  // Works as expected My favorite roaster is [Neighborhood Cafe](Coffee%20Roasters/Neighborhood%20Cafe.md).
In `Coffee Roasters/Neighborhood Cafe.md`:
# Neighborhood Cafe # This is how the magic happens [[Best Coffee Brew]] // Resolved to root-level/Best Coffee Brew.md
If in the future a file called Best Coffee Brew.md is added to Coffee Roasters the WikiLink would resolve to it because the notes are closer to each other. If a WikiLink can’t be resolved to an existing file nvUltra would leave the user with the choice to create a new note at the same level that the existing note is in.
-
That is how I have it in all my nvAlt files, though I used linked #tags for that purpose, where the tag can take you to a meta-note that collects or summarizes that tag across all your files.
Say I have files years in them (2019, 2020) and types of music (jazz, alternative, electronic). And for the most salient items I put a hashtag in front (#2019, #jazz) same way they are used in Twitter and LinkedIn and Wikipedia.
Here's some one-line nonsense file contents...
1. `20210311 Take Six.md` - [[#Beeple]] recorded his hit, "Take Six", in 2018, but it was released on a [[#2019]] [[#jazz]] EP by The Blockchains.
2. `2021 Todo.md` - Get the [[#jazz]] album mentioned in John's blog last week
3. `Christmas 2019.md` - [[#20191225]] Ed and Kaylee came over to celebrate. They brought their kids, Harry and Sally.Then there is a file, `#2019.md` that has two lines in it:
- `[[20210311 Take Six]]` by Beeple
- `[[Christmas 2019]]` Ed & Kaylee
And another file, `#Jazz.md` with these lines:
- `[[2021 Todo]]` get album
- `[[20210311 Take Six]]` from the new Blockchains EP
In nvAlt, the only way I found to do this tag linking was using wikilinks. To create the meta-files (#Jazz.md) I would search for all instances of `#jazz` and insert the link and description in the meta-file. This allows you to click forwards and backwards. But I think here in nvUltra, strict MMD parsing does not allow you to create a link like [[#Jazz]] because the initial # prevents the link rendering.
I have not yet decided how to mass edit my files so that they will work in both nvAlt (which I'm not yet ready to let go of until I know the Ultra can do what Alt did) and nvUltra and not lose the linking functionality as well as the search function. I also need to find my system of checkboxes, such as `[]` and `[x]' and `[ ]` and `[]read` that may be in the filename or in the file contents.
0
Please sign in to leave a comment.
Comments
1 comment