Recent commit to improve keycode merging broke which-key for me

[farzadmf]

Instructions: Replace the template text and remove irrelevant text (including this line) Warning: if you don't fill this issue template and provide the reproducible steps the issue could be closed directly.

Environment (please complete the following information):

• OS: MacOS / Linux

• (Neo)Vim version: v0.8.0

• vim-which-key version: 398adc5

• Have you reproduced with a minimal vimrc: No (please see below)

Describe the bug Sorry for not creating a minimal vimrc and close this if you think that's the only option, BUT I'd appreciate if you can help

I've been using which-key for as far as I remember, but a recent commit https://github.com/liuchengxu/vim-which-key/commit/9875baefb1d3e78abbf8f652a17e130744a37742 has broken my config without any change on my side

The error is this:

Error detected while processing function which_key#start[30]..<SNR>106_create_runtime:
line    7:
E116: Invalid arguments for function deepcopy
line   10:
E121: Undefined variable: runtime
E116: Invalid arguments for function <SNR>106_merge
line   14:
E121: Undefined variable: runtime
Error detected while processing function which_key#start[53]..which_key#window#show:
line    1:
E896: Argument of get() must be a List, Dictionary or Blob

As I mentioned, feel free to ignore and close. I know this must be because of something in my config, but since I haven't changed any which-key settings for QUITE a while, and my config has grown quite a bit, it's very hard to pinpoint what's actually wrong on my end without your help.

If you decide to help, it'd be greatly appreciated

[liuchengxu]

I suggest you adding some debugging prints to see why the error was raised and find some clue.

diff --git a/autoload/which_key.vim b/autoload/which_key.vim
index 1abc1e4..4d5e04d 100644
--- a/autoload/which_key.vim
+++ b/autoload/which_key.vim
@@ -146,6 +146,7 @@ function! s:create_runtime(mode, key)
     if type(s:desc[mode][key]) == s:TYPE.dict
       let runtime = deepcopy(s:desc[mode][key])
     else
+      echom 'mode: '.mode.', key: `'.key. '`, value: '.string(s:desc[mode][key])
       let runtime = deepcopy({s:desc[mode][key]})
     endif
     let native = s:cache[mode][key]

[farzadmf]

Hey @liuchengxu , so sorry for the delay, was busy and finally I decided to give it a go:

So, I get this:

mode: n, key: ` `, value: ''

And my s:desc[mode][key] is empty. Is there something I need to set in my config? Is it expected for it to be empty?

[liuchengxu]

Are you sure something like call which_key#register('<Space>', 'g:your_own_space_key_map') is called in your vimrc? You need to register the key before invoking it.

[farzadmf]

Hey @liuchengxu thank you for your reply

Turns out the commit now makes things case sensitive it seems, I had a call to which_key#register with <space>, and changing that to <Space> seems to have solved that issue!

UPDATE on this guy: I just noticed that the line that's actually allowing me to display the menu is this line:

nnoremap <silent> <leader> :<c-u>WhichKey '<space>'<CR>

I guess that's how it's supposed to be, right? (Sorry, as I mentioned, it's been a while since I set this up I've forgotten things)

---

However, I now see a new issue: I have set up a separate map for my visual, and I do like this:

xnoremap <silent> <Space> :<c-u>WhichKeyVisual! g:my_visual_maps<CR>

However, when I visual select something and press space, nothing happens and if I keep pressing some random keys (can be anything) for a few times, then my menu appears.

I must say, I haven't used this visual mapping for a while, so I'm not sure when was the last time it was working, but do you think it could be something with which-key? (I know it was working at some point)

[rene-descartes2021]

I'll take a look at those issues. I figured there might be edge cases so I left that PR open a long time while using it. I thought to fix #125 while I was at it, but hadn't gotten to that yet.

Minimal reproduction steps are very helpful toward illustrating the exact problems to fix.

[rene-descartes2021]

However, I now see a new issue: I have set up a separate map for my visual, and I do like this:

xnoremap <silent> <Space> :<c-u>WhichKeyVisual! g:my_visual_maps<CR>

@farzadmf Try this from the directions, with proper substitutions:

call which_key#register('<Space>', "g:which_key_map_visual", 'v')
vnoremap <silent> <leader> :<c-u>WhichKeyVisual '<Space>'<CR>

I'll look at why :WhichKeyVisual! {dict} might not work later.

[farzadmf]

Great @rene-descartes2021 , thank you, that seems to resolve the delay issue. Do you want me to close this as I think my issue seems to be resolved now?

[rene-descartes2021]

@farzadmf Sure, if someone else has problem they can open.

Yes, IIRC :WhichKeyVisual! {dict} will have a delay, as when passing the {dict} each time there is additional processing each time compared to the which_key#register() route. It has been a while so I don't recall details.

[tkapias]

I had the same problem after commit 9875bae.

• Before this commit I did not have to escape '<keycode>' in the data structure:

let g:which_key_map.b = { 'name' : '+Buffers-Tabs' }
let g:which_key_map.b['<Space>'] = 'Tab(next)'
noremap <Leader>b<Space> :tabnext<CR>
let g:which_key_map.b['<Tab>'] = 'Buffer(next)'
noremap <Leader>b<Tab> :bn<CR>

• now I have to:

let g:which_key_map.b = { 'name' : '+Buffers-Tabs' }
let g:which_key_map.b['\<Space>'] = 'Tab(next)'
noremap <Leader>b<Space> :tabnext<CR>
let g:which_key_map.b['\<Tab>'] = 'Buffer(next)'
noremap <Leader>b<Tab> :bn<CR>

It may help some user.

• The kind errors that I had:

Erreur détectée en traitant function which_key#start[28]..<SNR>28_cache_key[4]..which_key#mappings#parse :
ligne   19 :
E684: index de Liste hors limites : 0
E116: Arguments invalides pour la fonction maparg(raw_sp[0], line[0], 0, 1)
Erreur détectée en traitant function which_key#start[32]..<SNR>28_create_runtime[10]..<SNR>28_merge[24]..<SNR>28_merge[4]..<lambda>5 :
ligne    1 :
E741: La valeur de argument de extend() est verrouillée
Erreur détectée en traitant function which_key#start[32]..<SNR>28_create_runtime[10]..<SNR>28_merge[24]..<SNR>28_merge[4]..<lambda>7 :
ligne    1 :
E741: La valeur de argument de extend() est verrouillée