Support Markdown Notes style of wiki links

[Skn0tt]

Thank y'all for creating this wonderful VSC extension! I've been using it with Foam and quite liked it.

I noticed that Markdown Links doesn't pick up some of the wiki-links that Markdown Notes generates. This PR aims to fix this.

Motivation

Instead of writing [[how-to-find-interesting-ideas-david-perell.md]] (Markdown Notes' file naming convention), users should be able to write [[How to find interesting ideas - David Perell]] and still have it be picked up by Markdown Links' Graph.

What is PR does

This PR makes the graph ID scheme adhere to Markdown Notes' naming convention.

[tchayen]

Hi! Thanks for contributing!

I am not sure what changing the way of resolving IDs gives us here. It looks like the root of the problem is somewhere else, right? Could you help me understand what really causes it?

[Skn0tt]

Sure, sorry I didn't make that clear 😅 I'll describe my user story to show where the problem is.

I take notes using Foam which includes both Markdown Links and Markdown Notes.
I'll use the "Create new Note" command (provided by Markdown Notes) to create a new note with the topic "How to find interesting ideas". It creates a new file called how-to-find-interesting-ideas.md. I'll then open up another file and add a wiki link to the newly created note: [[How to find interesting ideas]]. Markdown Notes will understand the link even though it contains spaces instead of dashes.
But Markdown Links does not, unless you type the precise filename. And since [[how-to-find-interesting-ideas.md]] isn't very readable, that's unlucky. It also doesn't work with Markdown Notes' CMD-Click note creation.

This PR tries to fix that by making sure that different styles of wiki links to the same file are recognized as pointing to the same file. It does so by introducing the slugify function. It maps [[how-to-find-interesting-ideas.md]] onto the same ID as [[How to find interesting ideas]]. (I'd love for a better name for slugify, though 😅)

I'm pretty sure this is the root of the problem. Before, the ID function didn't identify files correctly b/c it returned different IDs for the same file, just because the specific syntax differed a bit. This PR makes sure that a file receives the same ID across different syntactical representations.

Sure, there are downsides to this approach: If there are two files how-to.md and how to.md, the Graph will show them as the same file.

[tchayen]

Ok, now I get it, thanks 😄 .

So this is what I mean when I am talking about several standards for linking.

We have for example support for Zettlr-style links, which assumes that we specify a regexp in settings and then the first occurence of a string matched by that regexp is ID of this file. Because of that we pre-read the whole directory tree to know in advance which files exist and which not.

Now we are about to add support for another standard, this time assuming that filenames normalized to URL slugs are uniquely identifying.

So I think that as long as we add an option to turn it on/off we are good to go (so we are not forcing users into this breaking change with no way to opt out).

@wgslr What do you think about it? Maybe we should follow with the same idea for Zettlr links and make it opt-in/out (not sure yet what should be default and what not for both solutions). Or maybe you have a better idea how to work with several systems for linking?

[Skn0tt]

Adding this as opt-in behaviour seems like a good idea with the different linking styles around.

I guess we'll add the Markdown Notes style to the default workspace settings of Foam then 😄

[wgslr]

I agree that in the fragmented wrold of note linking conventions we probably won't be able to provide behaviour that suits everyone out of the box, so switchable modes are the way to go. I think the main distinction is between "id defined in file content" and "file name is the id".

Some notes about the slugifying: as far as I know this is the function responsible for it in Markdown Notes. It normalizes a bit more characters than @Skn0tt's function.
And then there are also those noteNamesFuzzyMatch, noteNamesFuzzyMatchText functions which make the comparison case insenitive, which is especially important on Windows and MacOS (see #50).

Generally, I believe it's hard to maintain consistent behaviour between separate extensions, especially in such loosely defined matters like "similar titleness". It would be best to have some shared spec, or a library, defining this stuff. But that's getting ourselves into a xkcd#927 situation, especially since all of these extensions can and probably should support use cases separate from Foam.