Best practice for local file links?

[VimWei]

Hi, I have a question about the best practice for linking to local files.

1. Creating links: In a wiki page, I want to link to local files like abc.vim or xyz.py. When I press <CR> on the filename, wiki.vim creates a link like [abc.vim](abc.vim.md). However, I would prefer the link to be [abc.vim](abc.vim).

2. Opening files: When I press <CR> on a link like [abc.vim](abc.vim), wiki.vim opens abc.vim.md. I would like it to open abc.vim for editing instead.

This is the behavior I'm used to from vimwiki, and I find it quite intuitive.

With the current functionality in wiki.vim, I could just write the filename abc.vim in the wiki page without creating a link and use gf to open it. However, this approach has a couple of drawbacks:

• The filename is not visually distinct from regular text, making it difficult to see that it's a link.
• Since it's not a link, I can't use <Tab> to jump between it and other links.

If I use the format [abc.vim](abc.vim) to address these issues, it looks like a link and I can jump to it with <Tab>. I can also open the file with gf. However, there's a potential issue: using gf with the cursor on the [abc.vim] part of the link fails because Vim searches for [abc.vim] instead of abc.vim, causing it to freeze. It only works correctly if the cursor is on the (abc.vim) part.

Is there a better way to handle this use case?

Thanks for your help

Edit: I saw in the documentation that we can use g:wiki_link_schemes to override default functions. I'm having trouble figuring out how to use it for the specific situation I mentioned. Any guidance would be appreciated.

[lervag]

1. Creating links: In a wiki page, I want to link to local files like abc.vim or xyz.py. When I press on the filename, wiki.vim creates a link like [abc.vim](abc.vim.md). However, I would prefer the link to be [abc.vim](abc.vim).

Pressing <cr> on text is something I only do for creating wiki links. I never considered that you might want to "toggle" a filename and create a link to other files!

I think it could be interesting to look into this. Perhaps I should add that. It seems "intuitive" that the behaviour of <cr> is something like this:

1. If the text (either selected text or whatever is beneath the cursor) is a filename of an existing file, then the link should be a wiki link only if the filename extension is included in g:wiki_filetypes. If it is a filename to another file, then we should allow other behaviour (this is the lacking feature).

2. If the text (either selected text or whatever is beneath the cursor) is not a filename of an existing file, then we just create a wiki link.

2. Opening files: When I press on a link like [abc.vim](abc.vim), wiki.vim opens abc.vim.md. I would like it to open abc.vim for editing instead.

A link url always has a scheme, and markdown links will have a default scheme "wiki". And the default behaviour for wiki schemed urls is that they are markdown files.

For other files, you should use a different scheme, for instance the file: scheme: [abc.vim](file:abc.vim). You can customize the behaviour of opening url's for the different schemes. This is what I do; I configure g:wiki_link_schemes here https://github.com/lervag/dotnvim/blob/8ef31be364010945f4c2d655d2a2dee96ce59b92/lua/lervag/init/packages.lua#L81-L129 and I use a custom file handler defined here: https://github.com/lervag/dotnvim/blob/main/autoload/personal/wiki.vim.

I highly advice that you read the section :help wiki-link, including the section on the link schemes.

I saw in the documentation that we can use g:wiki_link_schemes to override default functions. I'm having trouble figuring out how to use it for the specific situation I mentioned. Any guidance would be appreciated.

I will be glad to help, but I would need to better understand your desired "goal". Also, I don't know if you are using Vim and Vimscript or Neovim and Lua.

[VimWei]

Thank you for your careful guidance. I think I know how to handle it now!

My objective extends beyond default markdown links to include additional link types, particularly the :help wiki-link you referenced. Most of my wiki notes can be handled with Markdown, but when learning certain programming languages, I often need to reference standalone files like Vimscript, Python, Lua, etc.

Despite thoroughly reviewing the full help documentation several times, I find certain aspects overly technical. Your practical examples have significantly improved my comprehension. PS: I mainly use Vim and Vimscript.

[lervag]

Thank you for your careful guidance. I think I know how to handle it now!

Glad to hear it's helpful!

My objective extends beyond default markdown links to include additional link types, particularly the :help wiki-link you referenced. Most of my wiki notes can be handled with Markdown, but when learning certain programming languages, I often need to reference standalone files like Vimscript, Python, Lua, etc.

Yes, that's familiar - I do the same sometimes. Having links that point to something "outside" of the wiki itself is very useful.

Despite thoroughly reviewing the full help documentation several times, I find certain aspects overly technical. Your practical examples have significantly improved my comprehension. PS: I mainly use Vim and Vimscript.

I try to keep the docs understandable, but it's hard to make it fully accessible to everyone regardless of experience and technical know-how. If you have ideas for how to improve it, then I'll be grateful to get suggestions or PRs.

[VimWei]

Sharing my setup here for anyone who might find it useful.

https://github.com/VimWei/vim-init/blob/7848c337c4f7c3832dcbba8053776b821a7351f9/plugin-config/wiki.vim.vim#L113-L138

[lervag]

By the way: Please note that you should use backquotes when you write things liks <CR>. If you omit the backquotes, then it will be interpreted as an HTTP tag and will not be displayed. Also, I would suggest that you avoid hardbreaking lines on GitHub comments and posts. Further, discussions on GitHub are based on threaded comments. So, when you add additional information, I would advice to use the edit feature: