# anyone know how to improve how filepaths are handled in vimwiki?

In VimiWiki plugin, using markdown syntax we can hyperlink to other files... it's great but the problem is how file paths are interpretted.

Linking to a file in the current directory is simple and flawless.

The issue is when you want to link to a subdirectory of a different parent directory...

If I'm in /home/alec/Work/ahillio_labs/human-ecology/ editing the wiki files there and I want to link to another wiki file in /home/alec/Documents/wiki/target-file I can't type that full file path, nor can I type ~/Documents/wiki/target-file (both of those result in Vim trying to create a new directory as a subdirectory of the current one), I have to type ../../../Documents/wiki/target-file which is minorly troublesome for me every time I do it.

It appears that there may be a solution integrated into the plugin at some point (the issue is currently stalled) that might(?) address the issue I'm facing, but it doesn't explicitly describe the symptoms I'm trying to resolve.

Has anybody else worked around this issue?

How filepaths are currently handled is problematic for the situation OP described. But additionally, given the same feature, that filepath handling also leads to the following inconsistency.

Suppose I have two wiki names myWikiPrsn and myWikiWork, pointing to ~/p and ~/w respectively. If the file I'm in happens to be in a directory somewhere under ~/p, then (wn.myWikiPrsn:thisFolderNow/1.md) tries to open subfolder thisFolderNow wherever that current file happens to be whereas (wn.myWikiWork:thisFolderNow/1.md) tries subfolder ~/w/thisFolderNow and looks for file 1.md there.

Given the current filepath handling specification there is of course a logic to this (if you're going to jump to ~/w/ from somewhere under ~/p where else can you jump to?). But having filepath handling that follows, say, a distinction between "relative to root at myWikiPrsn" vs "relative to current folder" would be very helpful. If I then decide to move the location of the file, its pointer locations would still be correct. Moreover, such filepath handling would then be consistent with how we manipulate files within vi (say when we open files with ":e"). And, an argument could be made for consistency across wn.myWikiPrsn:thisFolderNow/1.md and wn.myWikiWork:thisFolderNow/1.md usage.

For those unfamiliar with the concept, my myWikiPrsnand myWikiWork are vimwiki names I use to point real locations in my files, via their .path component. That way when I move my folder locations (to rebalance loads for instance) all I have to do is adjust the two .path lines in this section of my .vimrc

"Multiple Wikis
" https://opensource.com/article/18/6/vimwiki-gitlab-notes
"
" Use wiki names via :h vimwiki-option-name
" Clone off a default https://github.com/vimwiki/vimwiki/issues/365
let myWikiDefault = {}
let myWikiDefault.syntax = 'markdown'
let myWikiDefault.ext = 'md'
"
let myWikiPrsn = copy(myWikiDefault)
let myWikiPrsn.path = '~/0/Floor/1/VimWiki/'
let myWikiPrsn.name = 'myWikiPrsn'

let myWikiWork.path = '~/0/Light/1/VimWiki'
let myWikiWork.name = 'myWikiWork'

let g:vimwiki_list = [myWikiPrsn, myWikiWork]

• Welcome on the Stack Exchange! Pro tip: never post an answer with "This is not an answer, but...", this is like saying to a cop: "I have a kilo amphetime by me, but I still love you". Instead, try to formulate the post looking the possible most answer-like. The most important helping factor: partial answers are answers and remain. Oct 28, 2020 at 7:46
• Could you explain what wn.myWikiPrsn: and wn.myWikiWork: are?
– alec
Oct 28, 2020 at 16:18
• @alec - I've rewritten my answer to address your question. Couldn't fit it into this comment box. Oct 29, 2020 at 11:48
• @DannyQuah what about the wn. part? How does that fit into this? Is it a function provided by vimwiki? If so it mapped to given keybindings or how does it get invoked?
– alec
Oct 29, 2020 at 13:21
• @Alec - take a look at github.com/vimwiki/vimwiki/blob/master/doc/vimwiki.txt // Interwiki~ for Named Interwiki Links Oct 29, 2020 at 23:14