Closed kitsugo closed 7 months ago
Thank you for the PR, @kitsugo . I really appreciate it. It works as you intended.
I do have a suggestion. I intended kiwi.nvim to be useful for taking notes that could be opened with other markdown note taking apps like Obsedian. And when I tested in obsedian, .
refers to the current directory.
When you add a link to a file inside another file inside the same sub-folder, it should only use ./subfile.md
and not ./sub/subfile.md
.
I understood that the second approach helps to understand the links better when viewing. For support with other note taking apps, I would prefer to choose the first method over the second.
Thank you for the review, @serenevoid
I agree the first approach actually makes more sense than I had initially thought.
Given that the context of the buffer will be inside the subdirectory, it makes sense that any links are then also in context (relative) to the currently opened markdown file. In fact, using some path completion plugin / other IDE will makes this more evident. (Typing ./
shows all files in the same directory as the current markdown file is in)
For nested subdirectories this also seems logical.
If file.md
is inside wiki/sub1/file.md
, then creating a link inside of it (newfile)[./sub2/newfile.md]
will point to the file wiki/sub1/sub2/newfile.md
I've changed my PR to utilize this implementation now.
As is described in issue #10 kiwi will always create new MD files in the root directory of the wiki, even if a wiki file is already within a subdirectory. This PR changes the behavior so that kiwi will respect the subdirectory structure. In particular, it utilizes the second approach mentioned in the issue above, by generating a relative path from the wiki-directory and then also opening the buffer there.
Example: Creating a new link inside
wiki/sub/file.md
will create this link:[newfile](./sub/newfile)
. The buffer of the new fileNewfile.md
will then be inside the sub directory too. That is, if the buffer gets written, it is written to:wiki/sub/newfile
I've chosen the second approach for implementation, that is, having the relative path in the markdown link since this makes the links more intuitive and transparent when viewing the wiki-directory as a "root directory". If one explicitly sets a link to be
(./file)
within another file that is in a subdirectory, that link will reference back to the root-directory of the wiki.closes #10