feature: keymaps action should be optional about nixvim

[GaetanLepage]

This is the behavior we had before.
We removed it when adding the aforementioned plugins.which-key.registrations option.

That being said, I get your point. I have no major reason to oppose this change.
What do you think @traxys ?

[MattSturgeon]

I don't feel strongly about this either. It just felt strange that you can use keymaps to register most of your key descriptions, but not all.

Looking ahead, if this is accepted and plugin-specific keymaps get refactored to be consistent with keymap, perhaps plugins.which-key.registrations would become redundant and end up being deprecated?

[GaetanLepage]

Actually, I remember now.
We used to allow this behavior but decided to remove it.
Basically, one entry in the keymaps option leads to one call of vim.keymap.set.
The latter does not support nil rhs argument. Hence, the behavior for specifying a keymap without an action does not make sense (if you forget about which-key.
We (at least I) don't want our core keymaps option to depend on a third-party plugin.

[MattSturgeon]

Actually, I remember now. We used to allow this behavior but decided to remove it.

Yeah, this would essentially be reverting that... So I'll appreciate if this is considered "won't fix".

Basically, one entry in the keymaps option leads to one call of vim.keymap.set.

What if the keymaps list used for vim.keymap.set is filtered to remove keymaps without an action? The inverse filter could be used to register which-key descriptions.

I get that this adds complexity, but I think it would be more intuitive.

We (at least I) don't want our core keymaps option to depend on a third-party plugin.

I agree core functionality shouldn't depend on plugins, but I think plugins should be able to enhance core functionality.

I think it would be enough to document that key descriptions have no effect without which-key... Perhaps print a warning if a null-action keymap is defined without which-key being enabled?