Create zettels in a subfolders?

[ferdinandyb]

Is it possible to configure vim-zettel so that it creates zettels in a subfolder instead of the root of the wiki? If not, would this be relatively easy to implement, like prepending filenames with a folder, or does other parts of the code assume the zettels are in the root folder?

[azthec]

I agree that this should be a standard configuration.

If you want a work around I ended up splitting my vim-wiki into two so that this could be possible.

https://github.com/michal-h21/vim-zettel/blob/master/doc/zettel.txt#L254

[ferdinandyb]

So your second vimwiki is a subfolder of the first? Do they play nicely together? Although I'm planning to spend a bit of time on a PR in the near future.

[azthec]

Actually I have it setup as two separate wikis, in a git repository folder. However I tested and vim-zettel commands still work fine in subwiki like you said, as long as you change into the subwiki directory first.

This likely works due to the load order for the wikis https://github.com/michal-h21/vim-zettel/blob/master/doc/zettel.txt#L130

[michal-h21]

The current code expects all notes to be in one directory. The trick with multiple wikis can prevent some errors, but I am not sure if everything works as expected. If anyone can fix this issue, I will gladly accept any PR!

[ferdinandyb]

@michal-h21 My idea would be to simply allow the user to define a path relative to the vimwiki root to a specific folder where all of the zettels would go. Without having looked at the code yet, that seems like an easy fix as long as you know all the places where you need to prepend the path. E.g.

   let g:zettel_options = [{}, {"front_matter" : [["tags", ""], ["type","note"]],
   \ "template" :  "~/mytemplate.tpl", "zettel_dir": "subfolder/zettels"}]

would place all notes in /path/to/second/wiki/subfolder/zettels. I haven't yet looked at the code, but I hope it's not too complicated.

[michal-h21]

We use Vimwiki's path-handling function and variables in many places in the code, so the changes would be big, and the possibility of breaking things would be big too. But as I said, I am not opposed to PR that enables it.

[ferdinandyb]

I started looking at the code and yeah, it's not as straightforward as I thought, but let's see what I can come up with :)

[ferdinandyb]

Do you mind if I open a WIP PR as I start hacking?

[michal-h21]

Yes, it is not straightforward, it will need a lot of changes, but it can be an opportunity for some code cleanup.

So should I wait for the merging of your PR?

[ferdinandyb]

I think #138 can be handled separately since as far as I see it, that seems to be a straightforward bugfix (at least it was not behaving as the docs says it should).

[michal-h21]

Ah, OK, so I merged it. Thanks!

[ferdinandyb]

@azthec if you're interested, can you check/test my PR #139 ?