vim

walterl 2022-10-07T00:05:56.085549Z

Has anyone else noticed :WhichKey '<LocalLeader>' bombing out with errors like these?

Error detected while processing function which_key#start[20]..<SNR>159_cache_key[4]..which_key#mappings#parse:                                                                                                                                                                                                           
line   19:
E716: Key not present in Dictionary: "rhs])"
E116: Invalid arguments for function call
line   28:
E716: Key not present in Dictionary: "rhs, '<SID>', '<SNR>'.mapd['sid'].'_', 'g')"
E116: Invalid arguments for function substitute
line   36:
E716: Key not present in Dictionary: "display !~# 'WhichKey.*'"
line   19:
E716: Key not present in Dictionary: "rhs])"
E116: Invalid arguments for function call
line   28:
E716: Key not present in Dictionary: "rhs, '<SID>', '<SNR>'.mapd['sid'].'_', 'g')"
E116: Invalid arguments for function substitute
line   36:
E716: Key not present in Dictionary: "display !~# 'WhichKey.*'"
line   19:
E716: Key not present in Dictionary: "rhs])"
E116: Invalid arguments for function call
(It goes on for a few pages.) I'm guessing it's due to Conjure creating mappings directly (somehow) to Lua functions:
:map <LocalLeader>
...
n  <BS>rc      *@<Lua function 435>
                 Clear the refresh cache
n  <BS>ra      *@<Lua function 434>
                 Refresh all namespaces
n  <BS>rr      *@<Lua function 433>
                 Refresh changed namespaces
...

Olical 2022-10-07T12:47:54.369479Z

This is because Neovim has direct to Lua function mappings now which lack the RHS portion of the mapping data. So plugins that try to access that blindly will now throw on ANY Neovim mapping that points at a Lua function. The old which key needs a safe check to support nil RHS or you can use the nvim / new one. If Conjure didn't trigger this bug, some other plugin would eventually, I'm just hopping on the Lua mapping train early because it's so much better and allowed me to fix bugs with vim repeat integration.

πŸ‘ 2
walterl 2022-10-07T00:06:25.929709Z

That's https://github.com/liuchengxu/vim-which-key

walterl 2022-10-07T00:06:54.091049Z

And yes, my <LocalLeader> is mapped to <BS>

walterl 2022-10-07T00:07:40.276539Z

I'd switch to which-key.nvim, but <BS> doesn't work with it

walterl 2022-10-07T00:10:27.721659Z

Well, it works after manually executing :WhichKey <LocalLeader> 😡

2022-10-07T00:14:01.769029Z

Internally, vim converts leader to the leader key at read time so internally it’s not <leader>ff, it’s \ff

2022-10-07T00:14:09.347289Z

Is that the case here?

walterl 2022-10-07T00:18:39.888999Z

Don't think so. This looks plugin-specific.

πŸ‘ 1
walterl 2022-10-07T00:20:17.109939Z

Closest I can get which-key.nvim to behave like vim-which-key, is to add nnoremap <silent> <LocalLeader> :WhichKey '<LocalLeader>'<CR>, even though the README specifically says not to

πŸ˜‚ 1
walterl 2022-10-07T00:25:53.851319Z

Oh well, I guess that half-working hack with which-key-nvim is better than half-broken vim-which-key πŸ€·β€β™‚οΈ πŸ˜