Wikilinks don't work in pages located in subfolders

[t7ko]

Wiki allows creating pages in subfolders. It's really easy, try hitting enter on something like [[a/b]], and it will create you a folder a and a page b in that folder. But now, try adding a link to existing wiki page in that a/b. e.g. [[index]]. And suddenly it turns out it will try to look not on the top level, but inside a/ subfolder. If I now want to reference any page, I have to prepend ../ in all wiki links: [[../index]].

Now, I think this is not right. Wikilink must work the same way, no matter where it is located. Suppose I want to copy/move some text from this file to a page on top level. What now, go manually thru the text copied and fix all wikilinks, removing ../ from them?.. It's ok for small piece of text, but suppose I want to move entire page? Or all pages in a subfolder?

On the other hand, if I try link completion in a page in a subfolder, it turns out to be aware of this behavior -- all links have ../ prefix. So maybe it was intended to work this way. In which case it would be nice to know why.

[EinfachToll]

Yes, it is intended to work this way. @habamax, the original creator of Vimwiki said so, if I remember correctly. Although it's not problem-free, as you notice, it makes sense. If you move things up or down in a hierarchy, you cannot expect that links from one item to another item in the hierarchy still work. Personally, I avoid this problem by not using subdirectories at all ;)

A solution that just came to my mind would be to distinguish between relative links [[subfolder/file]] and absolute links [[wiki0:subfolder/file]]. If we are in, say, ~/my_wiki/a/index.wiki, the first one would link to ~/my_wiki/a/subfolder/file.wiki and the second one to ~/my_wiki/subfolder/file.wiki.

[t7ko]

Did @habamax explain why it was intended that way? I'm not seeing the use case which would explain it -- I guess because I'm too new to vimwiki.

And, these are not absolute path. They are all relative. [[wiki0:index]], when placed in a page in a subdirectory -- tries to open index in that same subdirectory, not on the top level of wiki#0.

So my problem with current behavior is, the page [[Test/Page]] kind of belongs to the wiki, but any normal link like [[index]] when placed in that page will not open an index page in the current wiki. So it's not like it really belongs to a current wiki, but rather some kind of a sub-wiki, almost isolated sand-box.

I'm OK if it was intended, but I'd like to understand a usage scenario that it serves to. And I can clearly see useful scenarios for the opposite behavior. Or maybe there was some fundamental problem with implementing this "opposite" behavior.

[EinfachToll]

Yes, [[wiki0:index]] currently is a relative link, too. The intention of the last paragraph in my last comment was to make a proposal for a change of Vimwiki.

A use case is not too hard to imagine. Directories are some kind of namespace. So, if I have e.g. in my wiki a folder programming where all files related to programming sit, you can make a link [[Go]] to the file programming/Go.wiki which is all about the Go programming languages. If you have another directory about board games, you can make a link [[Go]] which links to a file which is all about the chinese board game called Go. Again, I personally wouldn't do it like this, but looking at the past bug reports, it's not like nobody is using subdirectories.

[t7ko]

OK, got it, thanks for the scenario. It makes sense now; so much that I already see how I will use it in my wiki. Cool!

[t7ko]

Now that I have a scenario in mind, I have another idea. It would be really cool if name resolution worked like this:

• Search in current "module" (subfolder).
• Search in sub-folders. Use single match, report error for multiple mathes (or let user choose).
• Search in upper folder.
• Search in it's subfolders.
• Go one more level up and repeat, until you reach root folder of the wiki.

Kind of what upward search does in vim -- see :help starstar, "2) upward search". The glob() in vim does not seem to be able to do upward search though.

[EinfachToll]

Naaa, don't exaggerate it. Which problem are you trying to solve? If the user doesn't really know how the link to a desired file looks like, there is the omni completion to help them. Also, there can be problems when you want to create a new file. If there is another file with the same name in another folder, it is opened instead.

[nfarrar]

This is also an issue for me. I use vimwiki with several separate wikis ... my "default" wiki contains public information (nothing private) that could be published to a site (if I ever get around to it). There are several thousand documents from the past couple years, arranged in nested directories. Here's a few pages and how they're arranged:

applications/git/index.wiki (and then various sub pages of notes about git)
applications/gpg/index.wiki
applications/ssh/index.wiki
applications/tmux/index.wiki
electronics/arduino.wiki
electronics/beaglebone.wiki
forensics/imaging.wiki
programming/assembly/index.wiki
programming/python/packaging.wiki
os/osx/index.wiki
os/osx/plists.wiki
os/osx/defaults.wiki
os/debian/apt.wiki
reversing/win32api.wiki
woodworking/joinery.wiki

For navigation & searching, I use a combination of CtrlP & ag (ctrl-p does fuzzy name matching on the documents from the current vimwiki path, which works perfectly). Ag (with a little configuration) does lightning-fast pattern matching across the file content from the current directory - again, perfect.

My interest in this issue is from a pure publishing standpoint. The built-in commands disregard nested folders (and I agree with @t7ko that this is odd). So in my 'default' wiki root:

~/Wiki/default

which contains:

index.wiki
applications/**/*.wiki
electronics/**/*.wiki
os/**/*.wiki
(... etc)

When I run the command :VimwikiGenerateLinks it only generates:

# Generated Links
  * [[index]]

With my current workflow, I've got six separate wikis organized by their use:

• default - non-sensitive notes
• words - a blog of sorts
• work - notes from work
• scratch - thought catching
• home - home projects & such
• backup - dupes & outdated

If I'm understanding correctly the intended workflow is to create a separate wiki for every folder in each of my wikis. I see how that would be appropriate for someone who doesn't take a lot of notes. But for heavier use-case scenarios, I don't see why nesting folders wouldn't be expected.

In any case, I stumbled across this issue while looking around to see if anyone else had already tackled this issue. It would be nice to have support for nested directories baked into vimwiki, but I may just tackle it with some custom vim functions wrapping an external python script if there's no interest in having it included.

[EinfachToll]

@nfarrar: there is no “intended workflow”, it's just that some things are possible and some are not. Although it's interesting for me to read how other people organitze their wiki, I don't understand what your problem is. Subdirectories are supported by Vimwiki, you can link to a file inside nested directories like this: [[applications/git/index]]. The problem mentioned here is that currently all those links are relative, that's why I suggested to change the meaning of links with an explicite wiki scheme from relative to absolute, that is, if you have a link [[wiki0:index]] in the file applications/git/index.wiki, it links to index.wiki in the wiki root. At the moment, this link would link to itself. Opinions are welcome.

[t7ko]

@EinfachToll : the reason I proposed that name resolution thing is, I don't like the idea of using explicit wiki index as the only way to specify absolute paths. That's like a "magic numbers" in programming. Anything hard-coded is baaaad and needs be avoided etc. So how about using linux-style path convention instead? [[index]] means index in current folder, [[/index]] refers to top-level index.

[protist]

IMO, [[wiki0:index]] looks perfect. From the number in it, I presume that you are also considering [[wiki1:index]], etc.? I'm not sure what you were thinking, but 0 as the current wiki seems to make sense, then perhaps 1 as the first registered wiki, and so on?

I think [[/index]] is not so good, because I immediately think of the root directory in the full filesystem.

This is slightly off-topic, but also relates to relative links. I wanted to link to a PDF file in the same directory as my wiki. I could use [[file://~/my_wiki/a/file.pdf]], but there doesn't seem to be a way to link relative to the current file. Ideally, assuming the wiki page and PDF are in ~/my_wiki/a, there should be some kind of syntax that allows referencing [[file://file.pdf]]. I tried [[file.pdf]], but currently vimwiki will automatically create file.pdf.wiki. Similarly, there should be a way of referencing files (and images) from the base directory of the wiki, perhaps using something like [[file://wiki0:a/file.pdf]].

[protist]

Also, FWIW, zim uses [[:index]] for the top level index file. This also seems reasonable.

[protist]

Sorry, one more post. Is there a way to wikilink to absolute paths in the meantime? [[/path/to/my_wiki/a/subfolder/file.wiki]] doesn't work, as vimwiki tries to be too clever and prepends the current directory's path. I am loathe to use relative paths, as I am liable to move entire directories as sub-topics expand or contract.

[EinfachToll]

IMO, [[wiki0:index]] looks perfect. From the number in it, I presume that you are also considering [[wiki1:index]], etc.? I'm not sure what you were thinking, but 0 as the current wiki seems to make sense, then perhaps 1 as the first registered wiki, and so on?

No, wiki0 is the first registered wiki. My thought was, that a link from your first wiki to the second wiki, where you always have to specify the wiki1 scheme, is always absolute to the root of the other wiki: [[wiki1:absolute/path]], so it's not unreasonable, that if you prepend the scheme of the current wiki to a link, it too is an absolute path. But the more I think about it, the best and most obvious solution is probably to just handle [[/file/path]] as absolute and [[file/path]] as relative path, even though it's confusing at first to some people like you and me ;)

This is slightly off-topic, but also relates to relative links. I wanted to link to a PDF file in the same directory as my wiki.

For that, [[local:relative/path/to.pdf]] should work.

Sorry, one more post. Is there a way to wikilink to absolute paths in the meantime? [[/path/to/my_wiki/a/subfolder/file.wiki]] doesn't work.

As a workaround, take a look at :h VimwikiLinkHandler, especially the second example. If you put it in your .vimrc, a link like [[vfile:/path/to/my_wiki/a/subfolder/file.wiki]] or the like should work.

And maybe I find some time to add relative paths to Vimwiki. Maybe it's easy, maybe not.

[protist]

Oh! I was totally confused. I did have a read of parts of the help, but I expected references to [[local:…]] and [[wiki0:…]] to be in the "Links" section, not the "Scheme" section. In any case, these are totally acceptable usages. I think the current interpretation of [[wiki1:relative-to-root/path]] is perfect.

I also checked several online sources, and didn't come across these syntaxes. Perhaps it'd be possible to add it to the README.md? Also, I found a PDF that was for the old version of vimwiki. Would it be possible to update this too?

No, wiki0 is the first registered wiki.

Ah, okay. However, if users were to change the wiki order, or delete/split a wiki, these links could be broken. Perhaps it'd be useful to add some syntax for the current wiki, regardless of the order in which they are registered. Perhaps [[:path/page.wiki]] or [[wiki:path/page.wiki]] or something similar?

But the more I think about it, the best and most obvious solution is probably to just handle [[/file/path]] as absolute and [[file/path]] as relative path, even though it's confusing at first to some people like you and me ;)

I'm not 100% sure what you mean here. When you say "absolute", do you mean "relative to the wiki base"? If so, then I think it's not the best option, because (as mentioned previously), /file/path strongly suggests the root of the filesystem to me (and is used that way in other parts of vimwiki's syntax). Actually, I'm not sure what you mean by relative path here either. Aren't we talking about links in other wikis?

[protist]

Oooohh, hang on. This is really confusing. If you are editing wiki1, a link to [[wiki1:path/page.wiki]] is relative to the current page's directory. However, if you are in wiki0, this same link is relative to the base of wiki1. That seems really counter-intuitive to me. I guess in the meantime, I'll use the vfile format.

Obviously this is only a workaround at the moment, but it's quite ugly, because it marks links as "non-existent" (i.e. red background), you have to manually append .wiki, and pressing enter on these links opens up a new tab (although this is probably better than default!).

[EinfachToll]

Oh! I was totally confused. I did have a read of parts of the help, but I expected references to [[local:…]] and [[wiki0:…]] to be in the "Links" section, not the "Scheme" section. In any case, these are totally acceptable usages. I think the current interpretation of [[wiki1:relative-to-root/path]] is perfect.

I also checked several online sources, and didn't come across these syntaxes. Perhaps it'd be possible to add it to the README.md? Also, I found a PDF that was for the old version of vimwiki. Would it be possible to update this too?

At least we can add a link to the help file from the links section to the scheme section, to make things more clear. But yes, a cheat sheet would probably be useful, too. Still, if someone uses a software or a device, they have to read the manual.

Ah, okay. However, if users were to change the wiki order, or delete/split a wiki, these links could be broken. Perhaps it'd be useful to add some syntax for the current wiki, regardless of the order in which they are registered. Perhaps [[:path/page.wiki]] or [[wiki:path/page.wiki]] or something similar?

But, a link without any scheme (like [[bla]]) is already a link to a file in the current wiki. I don't know if we understand each other correctly. There is a distinction between wiki links and links to arbitrary files. Wiki links start with the scheme wikiX: (where X is the number of the target wiki, if you want to link to a file of another wiki) or no scheme at all (if the target file is in the current wiki, which is the most frequent usage). They don't need to include the .wiki extension.

And, at the moment, wiki links that link to files in the current wiki (either because they don't have a scheme or because they have the scheme wikiX:, where X happens to be the number of the current wiki) are relative, that means, the target of the link depends of in which subdirectory you are in while you press Enter on that link. If you have a '~/mywiki/a_subdir/file.wiki' and in this file a link [[index]], it would bring you to '~/mywiki/a_subdir/index.wiki'.

And, yes, if you have a link to another wiki, like [[wiki3:path/page]], then it's an absolute path, because a relative path makes no sense. It's the same thing like on Windows, where the file system has more than one root, e.g. C: and D: and so on. You can't really make a relative path from a file in C: to a file in D:

Aside from wiki links, there are links to external files. They must have the file: or local: scheme and they must include the file extension. [[file:path/to/file.ext]] is for absolute paths, [[local:path/to/file.ext]] for relative paths.

That being said, there is a good chance for me to add absolute wiki links that work for the current wiki. That means, if you have a '~/mywiki/a_subdir/file.wiki' and in this file a link [[/index]], it would bring you to '~/mywiki/index.wiki' now. And I still think, the best choice is to prepend them with /, because with the distinction between wiki links and extern file links, there is no cause for confusion.

[protist]

Okay, I think we're on the same page for most of it. My interpretation of [[wikiX:path/page]] was that the wikiX: part was exactly analogous to C: in Windows. Hence, even if you were already in that wiki, I would have expected a link to that same wiki to be still be semi-absolute (to the base of that wiki). In any case, as long as it's consistent, then it doesn't matter, especially as vimwiki moves forward to the "absolute wiki links". Also, backward compatibility makes my expectations minor!

I do understand your logic with [[/index]], and I can accept that this interpretation makes sense also. Thanks for the comments and clarifications.

[EinfachToll]

@protist: I just made a commit which added handling of the / at the start of a wiki link. You can test it by checking out the dev branch of this repository. HTML conversion does probably not work yet.

[protist]

Great! It seems to work well. Thanks for the quick fix. One other thing that you probably haven't got around to fixing yet is the automatic highlighting of broken links (vimwiki-option-maxhi). At the moment, existing links are incorrectly shown as broken.

[EinfachToll]

@protist: Fixed

[protist]

Thanks for the quick fix. This works well. vimwiki correctly tracks the status of these links now.