Allow configuring which_key per buffer

[liuchengxu]

• allow customize which key configuration per buffer via b:which_key. If b:which_key exists, vim-which-key will use the buffer local config instead of the global one.
• provide some extensions for well known buffers by default, e.g., nerdtree, vista.

[zhaozg]

Are you ready to merge this?

[Mange]

Can I help out in some way to get this moving again?

[liuchengxu]

@Mange I have updated this branch, the extension should just work, but I haven't tested the b:which_key, you can try it and give the feedback here. b:which_key is just like the global one, but will override the global which key config when it exists.

[gquittet]

Great feature ! 💪
It was I'm looking for !
Is it possible to merge it ?

[liuchengxu]

@gquittet You can try this branch and give the feedback here, it's not well tested as I don't use it heavily.

[Mange]

I'm testing the branch now. As a test I added this to a ftplugin file:

" ftplugin/vimwiki.vim
let b:which_key = {}
let b:which_key.t = { 'name': 'wiki' }
let b:which_key.t.S = 'taskwiki-stats'

When press leader on one of those buffers I can tell all my original which-key definitions are gone, and I get this error message:

Vim(let):E121: Undefined variable: g:which_key#extensions#vimwiki#config

My wiki prefix is shown along with some native unlabeled prefixes. Pressing t shows only the following: S → a

Pressing it has no effect.

Removing those new lines, killing the buffer, and reloading it again restores original which-key functionality, and other file types were not affected during that time.

---

[EDIT:] I should add that I also tested the built-in extension for Vista, and it seems to work well. I get the new custom vista labels there but also some other stuff I do not wish to have there, mainly from GitGutter adding text objects.

[gquittet]

I found a solution as a workaround before the merge of this pull request

I created a ftplugin file, and I defined keybinding on buffer enter.
It can be useful to people who are interessed in this pull request.

[bew]

Hello, I'm seeing a few things that I think are not right for this plugin.

⚠️ I don't think adding default mappings for arbitrary extensions like this is a good idea, you have absolutely no guaranties that the user did not change the default mappings.

The plugin already has a neat mechanism to detect existing mappings and display them.
Adding default mappings description is the role of a vim-distribution or the external plugin (like coc) itself, they should not be included in vim-which-key. (or I think it will add unnecessary pressure to the maintainer @liuchengxu)

---

Another ⚠️: You say:

vim-which-key will use the buffer local config instead of the global one.

This is not right in my opinion, because your global mappings still exist, even in special buffers like nerdtree or vista.
I have a different use case for buffer-local mapping description:
What I was looking for when searching for an issue or a PR on buffer-local mappings, was to ADD mappings, not replace them.

So there would be the global mappings description, and some buffer would additionally have custom buffer mappings description.
I would like to use this plugin to show global mappings normally, and global + buffer mappings if they are available.

👉 I was thinking about extending the existing function which_key#register to support multiple entries per prefix, with an additional option to choose if we want to extend or replace the descriptions for that prefix, like:

call which_key#register("<space>", "g:which_key_map")  " Global descriptions
call which_key#register("<space>", "b:which_key_map", "merge_if_exist")  " Buffer-local descriptions

---

👉 I might make a PR of my own with what I have in mind, which I think would cover my use-case (global + local) and your use-case (global OR local) with minimal changes.

---

Edit: Do whatever you want, I moved to another which-key-like plugin

[grivasgervilla]

Hi, I am also interested in this feature. I have tried to define some keybindings for latex files. So I haved used de autocommand command to register the keybinding for .tex files using de Filetype option.

When I open a .tex file I can see this keybindings (SPC l in my case), but the problem is that if I open other file, for example a .py file, this keybindings are also available.