wiki.vim
wiki.vim copied to clipboard
WikiTags can't work under gvim 9.1 or neovim 0.10 + win 10 pro
gvim 9.1.0429 under win10 pro
- restart gvim 9.1.0429
:WikiTagsopen a dialog with tag-page list- filter with any text such as 'wiki' and
enter - Error messages:
Error detected while processing function 88[30]..<SNR>87_callback[25]..function 88[30]..<SNR>87_callback:
line 23:
Vim(let):E687: Less targets than List items
neovim 0.10 with telescope under win10 pro
-
:WikiTagscan work with default setting but not telescope under neovim 0.10 + win 10 pro, but neovim's defaultvim.ui.selecthaven't filter. -
With telescope:
- restart nvim 0.10
:WikiTagsopen a dialog with tag-page list- filter with any text such as 'wiki' and
enter - Nothing happen but change the buffer name to 'd'
compare:
:WikiTagSearchand:WikiPagescan work both gvim and neovim(Regardless of whether Telescope is used) under win10 pro.
my VIMRC:
Plug 'lervag/wiki.vim'
Plug 'junegunn/fzf'
Plug 'bullets-vim/bullets.vim'
if has('nvim')
Plug 'nvim-lua/plenary.nvim'
Plug 'nvim-telescope/telescope.nvim'
endif
and related plugin config:
- https://github.com/VimWei/vim-init/blob/master/init/plugins.config/wiki.vim.vim
- https://github.com/VimWei/vim-init/blob/master/init/plugins.config/telescope.nvim.vim
About g:wiki_select_method help doc:
- For the Lua backend and Telescope section, should there not be parentheses
()at the end? - For the Telescope section, is there an extra ` symbol at the beginning?
If let g:wiki_fzf_tags_opts = '--preview "bat --color=always {2..}"', some garbled text appears here, corrupting the screen.
but let g:wiki_fzf_pages_opts = '--preview "cat {1}"' is working:
Update: Under windows, there is cat but no bat. Ignore this.
First, I would be very glad if you could try and improve your grammar. I don't say that to be rude, it's just that some of your sentences are very difficult to understand. I think there are many great tools available today, e.g. Google translate and ChatGPT and similar.
gvim 9.1.0429 under win10 pro
- restart gvim 9.1.0429
:WikiTagsopen a dialog with tag-page list- filter with any text such as 'wiki' and
enter- Error messages:
Error detected while processing function 88[30]..<SNR>87_callback[25]..function 88[30]..<SNR>87_callback: line 23: Vim(let):E687: Less targets than List items
My first question is: what is the related configuration here? Is it the one you posted afterwards, i.e. https://github.com/VimWei/vim-init/blob/master/init/plugins.config/wiki.vim.vim? I'll assume so for the rest of my reply.
The error message you are seeing is from fzf, I think here:
https://github.com/junegunn/fzf/blob/590060a16b85270c19c605e8758cda16c4517086/plugin/fzf.vim#L1006
And it is quite hard to immediately understand what went wrong here. But I think it is this line:
https://github.com/lervag/wiki.vim/blob/5943633f66d8c50834baebd0354d8248df171be6/autoload/wiki/fzf.vim#L127
Perhaps you could help verify that. If you add the following code in that file on your side:
function! s:accept_tag(input) abort "{{{1
let l:key = a:input[0]
+ let g:__test = [a:input]
let [l:tag, l:file, l:lnum] = split(a:input[1], ':')
+ let g:__test += ["done"]
Then you repeat the steps you had to reproduce the error. After reproducing the error, can you report the output of :echo g:__test?
neovim 0.10 with telescope under win10 pro
I know it seems trivial, but it is very good if you can be fully explicit about the config you are using. E.g., in this case, I believe you changed g:wiki_select_method - but this is not in your wiki.vim.vim config file.
:WikiTagscan work with default setting but not telescope under neovim 0.10 + win 10 pro, but neovim's defaultvim.ui.selecthaven't filter.
I believe you are saying that WikiTags work as expected on Neovim with default settings, but that it does not work if you use Telescope. That is, it does not work with this config:
vim.g.wiki_select_method = {
pages = require("wiki.telescope").pages,
tags = require("wiki.telescope").tags,
toc = require("wiki.telescope").toc,
links = require("wiki.telescope").links,
}
Is my understanding correct?
My first question is: what is the related configuration here? Is it the one you posted afterwards, i.e.
Yes, the related configuration is detailed in the following link: https://github.com/lervag/wiki.vim/issues/365#issuecomment-2153863133.
After incorporating the g:__test lines and replicating the steps, the resulting output from :echo g:__test is:
[['', 'Wiki: d:/WeirdData/wiki/Vim/neorg.md:2']]
Is my understanding correct?
Yes, your understanding is entirely correct.
I organize my vimrc in the following way: Each plugin's related configuration is stored in a file with the same name as the plugin, followed by a .vim extension, located in the vim-init/init/plugins.config/ directory. When I disable/enable a certain plugin, its related configuration is also disabled/enabled accordingly. This method makes it easier to enable or disable particular plugins and their configuration, preventing them from interfering with each other. For specific implementation, see: https://github.com/VimWei/vim-init/blob/a4d8896cc91e9c4e7b29da1c4d62543d7761bdb3/init/plugins.vim#L241-L249
Therefore, I don't need to change any configurations in plugins.config/wiki.vim.vim and plugins.config/telescope.nvim.vim. I only need to modify whether the telescope plugin is enabled or not.
-
g:wiki_select_methoduse wiki.vim's default setting: Vim utilizes fzf, while Neovim employs wiki.ui_select. Because there is no configuration for g:wiki_select_method in plugins.config/wiki.vim.vim. In this case,:WikiTagscan work normally in Neovim but will cause errors in gvim.Plug 'lervag/wiki.vim' Plug 'junegunn/fzf' Plug 'bullets-vim/bullets.vim' -
Vim continues to utilize fzf, while Neovim has switched to using telescope. Because in plugins.config/telescope.nvim.vim, there is a configuration for g:wiki_select_method. In this case,
:WikiTagswill cause errors in both Neovim and gvim.Plug 'lervag/wiki.vim' Plug 'junegunn/fzf' Plug 'bullets-vim/bullets.vim' if has('nvim') Plug 'nvim-lua/plenary.nvim' Plug 'nvim-telescope/telescope.nvim' endif
I would be very glad if you could try and improve your grammar.
Thanks for your patience and understanding with my unclear expressions. Many of my previous expressions were actually completed with the help of ChatGPT, ^_^
Sorry for my very late reply - it's been a very busy month!
My first question is: what is the related configuration here? Is it the one you posted afterwards, i.e.
Yes, the related configuration is detailed in the following link: #365 (comment).
After incorporating the
g:__testlines and replicating the steps, the resulting output from:echo g:__testis:[['', 'Wiki: d:/WeirdData/wiki/Vim/neorg.md:2']]
Ah, thanks, that explains the problem! Since you are on Windows, and since Windows uses the d:/ to specify the drive and root instead of the unix variant which is simply /, the logic in this function breaks down. I've pushed an attempt at a fix!
Is my understanding correct?
Yes, your understanding is entirely correct.
:)
I organize my vimrc in the following way: Each plugin's related configuration is stored in a file with the same name as the plugin, followed by a .vim extension, located in the vim-init/init/plugins.config/ directory. When I disable/enable a certain plugin, its related configuration is also disabled/enabled accordingly. This method makes it easier to enable or disable particular plugins and their configuration, preventing them from interfering with each other. For specific implementation, see: https://github.com/VimWei/vim-init/blob/a4d8896cc91e9c4e7b29da1c4d62543d7761bdb3/init/plugins.vim#L241-L249
Yes, that sounds like a reasonable config concept.
g:wiki_select_methoduse wiki.vim's default setting: Vim utilizes fzf, while Neovim employs wiki.ui_select. Because there is no configuration for g:wiki_select_method in plugins.config/wiki.vim.vim. In this case,:WikiTagscan work normally in Neovim but will cause errors in gvim.
Yes, I think you're right.
- Vim continues to utilize fzf, while Neovim has switched to using telescope. Because in plugins.config/telescope.nvim.vim, there is a configuration for g:wiki_select_method. In this case,
:WikiTagswill cause errors in both Neovim and gvim. …
Let me know if my latest patch fixes things for you now.
I would be very glad if you could try and improve your grammar.
Thanks for your patience and understanding with my unclear expressions. Many of my previous expressions were actually completed with the help of ChatGPT, ^_^
No problem 😸
Thanks! I've upgraded the plugin and performed the same tests on Windows 10 Pro:
- gVim 9.1 with fzf: It is now functioning properly (there were errors before the update, but now there are none)!
- neoVim 0.10 with wiki.ui_select: It works normally (just as it did before the update).
- neoVim 0.10 with telescope.nvim: It still doesn't work, showing the same error as before the update—the buffer name changes to 'd' and the content is empty, instead of displaying the file corresponding to the wikitag.
Thanks! I've upgraded the plugin and performed the same tests on Windows 10 Pro:
gVim 9.1 with fzf: It is now functioning properly (there were errors before the update, but now there are none)!
neoVim 0.10 with wiki.ui_select: It works normally (just as it did before the update).
Great!
- neoVim 0.10 with telescope.nvim: It still doesn't work, showing the same error as before the update—the buffer name changes to 'd' and the content is empty, instead of displaying the file corresponding to the wikitag.
Huh. I think I missed this in your original report. I'll look into it.
Again I think it is because of the Windows path thing. But I'm not immediately sure how to fix it.
The problem is here:
https://github.com/lervag/wiki.vim/blob/ce6c49e7f4c0959b0503a5003edcf3410920f1d4/lua/wiki/telescope.lua#L70-L76
In line 72, we pass the file path to the value. The path is a full path and the value is what is used by telescope to open the file. Perhaps you could help investigate by adding something like this above the return {...?
vim.g.__test = entry
Then you can inspect the value afterwards with :echo g:__test and report the output here?
To be clear, it is somewhat hard for me to debug this because I don't use Windows.
I would expect that entry is a list/table with three entries, where the second one is a full path like this:
d:\WeirdData\wiki\IT\TiddlyWiki.md
Perhaps it will look like this instead:
d:/WeirdData/wiki/IT/TiddlyWiki.md
And if it does, then that might be the problem here.
Do you have shellslash enabled?
Do you have
shellslashenabled?
Yes, I have shellslash enabled.
:echo g:__test
- Add
vim.g.__test = entryabove thereturn {....in line 72. - Restart nvim.
:WikiTags, then search tagwikiand select the itemTiddlyWiki.md.:echo g:__test, and return the following message which is not aboutTiddlyWiki.md.
['python Python/Python-Module-of-the-Week/Python-Module-of-the-Week.md:2', 'd:/WeirdData/wiki/Python/Python-Module-of-the-Week/Python-Module-of-the-Week.md', 2]
Do you have
shellslashenabled?Yes, I have
shellslashenabled.
Can you check if you have the same problem if you disable shellslash?
:echo g:__test1. Add `vim.g.__test = entry` above the `return {....` in line 72. 2. Restart nvim. 3. `:WikiTags`, then search tag `wiki` and select the item `TiddlyWiki.md`. 4. `:echo g:__test`, and return the following message which is not about `TiddlyWiki.md`.
['python Python/Python-Module-of-the-Week/Python-Module-of-the-Week.md:2', 'd:/WeirdData/wiki/Python/Python-Module-of-the-Week/Python-Module-of-the-Week.md', 2]
This does in fact confirm my suspicion. I think, if you disable shellslash, that the path may become like a regular windows path with \ instead of /, and that this may fix the problem.
Alternatively, you could try to make the following change here: https://github.com/lervag/wiki.vim/blob/c60e6a5ba11d94b312e8f6025db0984adbefc344/lua/wiki/telescope.lua#L72
- value = entry[2],
+ value = vim.fn.tr(entry[2], '/', '\\'),
Can you check if you have the same problem if you disable shellslash?
Disable shellslash, and test with :set shellslash?, display noshellslash.
- Add
vim.g.__test = entryabove thereturn {....in line 72. - Restart nvim.
:WikiTags, then search tagwikiand select the itemTiddlyWiki.md.- The result is displayed as before: buffer name changes to 'd' and the content is empty.
:echo g:__test, and return the following message:['PDF Vim/Logseq.md:2', 'd:\WeirdData\wiki\Vim\Logseq.md', 2]
Ok, thanks. So, shellslash is not relevant here. I assume my suggested solution to apply the vim.fn.tr() function also does not help?
I assume my suggested solution to apply the
vim.fn.tr()function also does not help?
It does not help.
Bummer. To be honest, I don't really have a clear idea of what is wrong here. I think we will need to debug this from your end.
Are you familiar with Lua and some programming already? I believe the solution will require a small modification to the code in the picker function, here:
https://github.com/lervag/wiki.vim/blob/ce6c49e7f4c0959b0503a5003edcf3410920f1d4/lua/wiki/telescope.lua#L37-L81
I think the code until line 66 should be fine, really, and that this is related to the telescope API. But it's impossible to debug it for me since I can't reproduce it.
I have the same issue, but buffer name will be 'C' instead of d. I guess this is the drive letter.
Actually I got it working but I have to admit I'm not really sure why does it work. I looked at telescope's dev doc and found that there is a path argument to the entry_maker. I added it and it fixed the issue:
entry_maker = function(entry)
return {
value = entry[2],
path = entry[2],
display = entry[1],
ordinal = entry[1],
lnum = entry[3],
}
However, it would be good to understand what's going on here...
Actually I got it working but I have to admit I'm not really sure why does it work. I looked at telescope's dev doc and found that there is a path argument to the entry_maker. I added it and it fixed the issue: …
Did you fix this by making a change to wiki.vim? If so, could you make it more clear exactly what you did, then I could perhaps add it?
However, it would be good to understand what's going on here...
Agreed! Perhaps I understand it better when I see the proposed change?
Sorry, my mistake. You did show clearly the change. I'm pushing an update now.
It's a little bit strange, to be honest. I'm curious, does it work on your end if you use filename instead of path?
I've updated now; @VimWei if it's still relevant to you, please update and test.
It's a little bit strange, to be honest. I'm curious, does it work on your end if you use
filenameinstead ofpath?
Yes, filename works!
Cool; not sure which of these are most appropriate here, but filename is mentioned in the user docs. Perhaps I should change to that?
Although, if it works now, then it works, right?
If it ain't broke, don't fix it 🤣
Exactly! 😊
After the update, it is now functioning properly! Thanks!