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

Consistent relative linking #72

Open
phlind opened this issue Sep 25, 2020 · 8 comments
Open

Consistent relative linking #72

phlind opened this issue Sep 25, 2020 · 8 comments

Comments

@phlind
Copy link

phlind commented Sep 25, 2020

What I would like to achieve is a linking behaviour relative to the current file:

That means, if I am in subdirectory/note1.md of my wiki, type [[ to invoke the fuzzy search and

  • choose note2.md in the root directory, it should enter [[../note2]] as a link.
  • choose subdirectory/note3.md it should enter [[note3]] as a link.

Also, when I am in note2.md in the root directory and

  • choose subdirectory/note1.md, it should enter [[subdirectory/note1]] as a link.
  • choose note4.md in the root directory, it should enter [[note4]] as a link.

That would be consistent with the behaviour of invoking the autocomplete from vimwiki with Ctrl-x Ctrl-o. But of course, here I have to start typing ../no or /no first, depending on where I am in my wiki, and I have to know the beginning of the filename, because it's not a fuzzy search.

Additionally, this is basically the behaviour of Obsidian when choosing the option to create new links relative to the current file. I would like to achieve consistency also with that to be able to edit my notes from Obisdian and from vim, while keeping the ability to follow links from within both programms.

@linusboyle
Copy link

+1.
This feature is essential. For now when I use the built-in diary system of vimwiki and want to link to my zettels in a diary, the path is not handled correctly. @michal-h21

@rfhlmn
Copy link

rfhlmn commented Nov 29, 2023

I'm also interested in this feature, I have the same issue.

@michal-h21 , I'd like to try creating a PR for it.
As far as I understand the code, the call stack goes like this:

  1. [[ gets mapped to ZettelSearch
  2. ZettelSearch calls zettel#fzf#sink_onefile
  3. which calls zettel#fzf#wiki_search to figure out where to search, and then also how to format the resultant link
  4. zettel#fzf#wiki_search calls zettel#vimwiki#format_search_link to actually do the formatting

So should zettel#vimwiki#format_search_link do the figuring out of what the relative path between "where we are" and "what we want to link to" should be?

@michal-h21
Copy link
Owner

@rfhlmn I think it should work after the latest update if I understand it correctly. When I have a document in wikiroot/sub/test.md, the ZettelOpen should search in its contents, and it will create a correct link [test title](sub/test).

@rfhlmn
Copy link

rfhlmn commented Nov 29, 2023

@michal-h21 , that part works great, it's the other way around that doesn't:

If I'm in diary/2023-11-29.md and try to link to foo.md in the root of my Zettelkasten, the link that gets created doesn't include the ../ that it would require to work correctly. I land in diary/foo.md if I follow the link.

@michal-h21
Copy link
Owner

@rfhlmn ah, OK, now I understand. If you want to try it, I will gladly accept the PR.

@rfhlmn
Copy link

rfhlmn commented Nov 29, 2023

@michal-h21 , cool!

Is my understanding in the comment above correct? Is zettel#vimwiki#format_seach_link the correct place to do that?

@michal-h21
Copy link
Owner

@rfhlmnmaybe. you get the relative path to the wiki root in the formatting function, so you would need to test if the current file is in a subdirectory of the wiki root and add necessary ../, maybe even multiple of them.

@rfhlmn
Copy link

rfhlmn commented Nov 29, 2023

@michal-h21 , yeah, the logic of it I'll still have to figure out, to make it robust.
But it's the right place to start, I take it, so I'll start on that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants