Option for link reference style for ZK LSP support

[chris-sanders]

Describe the bug
Currently using ZK as a LSP with Emanote I'm finding that the wikilink and markdown syntax for file paths are incompatible. Would be nice to have support across the two.

Emanote:

• Wikilink: [[notes/my note|My Title]]
• Markdown: [My note](notes/my%20note.md)

Zk:

• Wikilink: [[../notes/my note|My Title]]
• Markdown: [My title](../notes/my%20note) optional .md, optional percent encoding

Additional context
I have found that if I use Emanote's Markdown syntax and leave off the file extension the link works however Emanote doesn't recognize it, marks it with the bad link CSS and doesn't process backlinks.

At the end of the day, I think it's just a matter of if links are processed relative to the note they are in or the root folder. Zk is going with fully relative right now, while Emanote does it based off of the root folder.

It's possible these are both valid, and I don't really have a strong preference. I just want to use them together :)

See: zk-org/zk#65

[srid]

I can see supporting this for regular Markdown links (with extension intact, to avoid needless magic) ... but not sure about overloading the wikilink part. How does Obsidian behave in comparison?

[srid]

Neuron is in maintenance-mode (bug fixes only), and I'm focusing my current efforts on its successor Emanote.

Emanote has adopted a diametrically opposite approach to The Archive, in part due to the use of Haskell. Wiki-links are looked up in a strict index of notes, and notes are indexed by all possible wiki-links to them. For eg., Foo/Bar/qux.md is indexed by [[qux]], [[Bar/qux]] and [[Foo/Bar/qux]].

For this reason, I think it will be tricky to implement the relative path case in wiki-links, so I probably will just ignore it ... to avoid taking on the cost of code complexity at a clear lack of benefit ... which apparent lack of benefit does have me ask the question of why would anyone want to use relative wiki-links in the first place? What is the point, if you can use regular Markdown links anyway? The whole point of wiki-links, as far as I understand, is to avoid having to specify the path to the target Markdown file, and "look it up" by its name. Besides, if you move your notes around - relative-path wiki-links will be broken.

[srid]

That said, I do have plans for better handling of the 'broken wikilink' scenario (the case where it matches against none of the indexes). Currently it just puts them in a span, using user-specified class ... but we can make Emanote fallback to doing a The Archive like search.

So, wiki-link "resolution" will happen in two phase: 1) look up the note index (strict), and 2) if that fails, fallback to more lenient search and display the results in popup or something (the user can manually navigate to one of the notes in the list).

[srid]

This in particular would be useful for ambiguous note targets. My private zettelkasten "composes" several other public zettelkastens ... so in a number of instances there are duplicate notes, and [[Foo]] will refer to two notes "Foo.md" but in different directories (in the published public zettelkasten it would just be one note). Currently "Foo" will be marked as ambiguous link - but it should display a popup on click, offering to navigate one of the two notes.

[mickael-menu]

Are you matching with wiki links the filename or title of the notes, or both?

What is the point, if you can use regular Markdown links anyway?

To avoid putting in a manual title which is required with a Markdown link.
Although I agree with you, I don't think wiki links should match relative paths. It makes more sense that they match any unique portion in the path or title, IMO.

[srid]

Wiki-links always use the filename (sans .md extension).

Often I use the title in the filename, eg: Hello World.md and then link to it as [[Hello World]] - which gives the appearance of linking using fuzzy title match, but it actually always looks up by filename.

(When the link renders on the published site, however, it will try to use the title if one is specified in the Markdown body, falling back to filename if none exists)

[chris-sanders]

From my understanding of the discussion and the current status.

ZK is making changes to match Wikilinks in some new ways including by filename.
Reference Bug: zk-org/zk#65
Reference PR: zk-org/zk#71

This will make Wikilinks generated via ZK work with Emanote, with appropriate template usage.

@srid do I understand correctly that you're planning for Emanote to support relative file paths for Markdown links?

If I'm understanding that correctly then there is a path forward for both link types, it's just a matter of implementation :)

[srid]

If we are talking about the link types below, then yes - since Obsidian supports them it'd be good to have them in Emanote.

[[notes/z5mj.md]]
[[notes/z5mj]]
[[../notes/z5mj.md]]
[[../notes/z5mj]]
[Note](../notes/z5mj.md)
[Note](notes/z5mj.md)
[Note](../notes/z5mj)
[Note](notes/z5mj)

Though nothing is planned in immediate timeframe (a bunch of things going on personally), but I'd welcome a PR if somebody wants to contribute!

---

In the code base, it might require thinking into how this would fit in the current use of ixset-typed indexing by routes, since we can't index relative paths; I suppose one trick, to ease implementation, is to look up the index without the ".." prefix, and then filter the results for the matching parent folder.

edit: Alternatively, write a Pandoc walk routine to translate ../foo to <baseDir>/foo.

[edrex]

It would be easy enough to fix the relative wiki links in my notes left by a succession of global replace operations.

I do see some utility in relative links, though, as a way to disambiguate "ambiguous links" where the same slug appears at different paths. It doesn't help the case where a note with the same slug path appears in two different unioned directories though.

For eg., Foo/Bar/qux.md is indexed by [[qux]], [[Bar/qux]] and [[Foo/Bar/qux]].

edit: Alternatively, write a Pandoc walk routine to translate ../foo to /foo.

Yes, a link target normalization step to resolve components using the current doc path

In Foo/Bar/A.md:

• ./B.md => Foo/Bar/B
• ../Baz/C => Foo/Baz/C

This would prevent resolving eg [[./Foo]] in a subdir to a Foo.md at the top level, but I think that's actually good.

[srid]

I think we should do this: #249 (to begin with)

[srid]

I added support for relative links in regular Markdown links in #268

And it should be fairly straightforward to do the same for wiki-links.