How to avoid registering keys with which-key multiple times?

[AckslD]

In my setup I don't call register_keymap only once since I like to keep my setup of plugins and their specific keybindings in separate files. At the moment each call to register_keymap calls which_key#register and setups up the keybinding to call :WhichKey. This is not really an issue, other than being not so clean and inefficient. It would therefore be better to register keys with which-key only once.

However, it is not completely clear what is the best way since we won't know when the user is finished settings up the various keymaps. One approach I have in mind is requiring the user to basically say when setting up keymaps is finished, perhaps at the end of the init.{lua,vim}. In order to keep the old behaviour for backwards compatibility and easy-of-use there could be two new functions added:

• preload_keymap which updates the textmaps and configures the key-bindings of that keymap (this happens only once anyway) but does not yet register with which-key.
• register_preloaded_keymaps: register all preloaded keymaps, i.e. the textmaps with which-key

If anyone has some thoughts/ideas feel free to let me know :)

[folke]

What about triggering this at VimEnter? After that, if keymaps change, re-register them (current behaviour).

[AckslD]

That's a great idea @folke :) I've implemented this, see #13. I also there added bufnr to the textmaps table as you suggested. Although not used yet since the upstream PR is not yet merged. Feel free to have a look at that PR if you have any other thoughts.

[klooj]

Fwiw, plenary.nvim has a function for reloading modules.

local relmod = require('plenary.reload').reload_module

R = function(name)
  relmod(name)
  return require(name)
end

I've been using R('keymaps.leader') on bufenter, which does not solve any of the problems you mentioned but may provide an easy workaround in the meantime.

[klooj]

As a sidenote, ultimately it may make sense to handle the actual mapping of keys without which-key. But once which-key is relegated to being used for the popup only, it makes also handling the popup in lua harder to resist and then ... "AcksID/neoKey"

edit: see #14 for example (cannot be merged as is).

[AckslD]

Thanks for sharing @klooj! Actually whichkey-setup already handles the mapping of keys and only delegates the popup with hints to which-key. So it's indeed tempting to just do the popup directly as well, solving all the current issues :)

[folke]

@AckslD if you're going that route, look into vim.lsp.util.open_floating_preview. Just used it myself for something unrelated and it's very simple to create pretty looking popups with borders, etc :)

[AckslD]

Cool, thanks @folke! I'll take a look at it and try it out to see what it would take before fully committing :)

[folke]

@AckslD I just released a full lua port of which-key 🙂

Buffer local mappings and native keybindings work as they should + plugin support. Added built-in plugins for marks, registers and presets for motions etc.

You can check it out at https://github.com/folke/which-key.nvim

Let me know what you think! If you have any ideas on possible features, let me know

[AckslD]

Awesome @folke, thanks for sharing! :tada:

[AckslD]

@folke I finally got time to try out your which-key lua port and just wanted to say that it's amazing :smile: Great work! I'll probably archive this repo in some time and recommend anyone to use your port instead of this wrapper :)

[folke]

Thanks man, appreciate it!