Default binding options

[KaspervdHeijden]

Hi, thank you for the amazing work!

With 0.11 I'm seeing an increase of default bindings, which on one hand is nice, but on the other hand not so much, since they are highly opinionated (although carefully thought out). Now I have to deal with breaking config (mainly gr to go to definition in normal mode).

I find myself active having to combat the default bindings. Please have an option to disable them partially. Some are nice, like gc / gcc / [<space> / ]<space>. So I would like a simple solution to disable less optimal (for me) ones. If more defaults come, we might have to combat these, too.

Expected behavior

Have a way to simply disable specific default bindings.

[nenahp]

:h grr.

If not wanted, these keymaps can be removed at any time using
|vim.keymap.del()| or |:unmap| (see also |gr-default|).

[KaspervdHeijden]

Hi, thank you for your reply. I know I can do that, but thats combatting defaults. I would like to maybe opt-in on defaults instead.

For gr, I also needed to disable whichkey and mini.clues for the gr group, and add a nowait = true.

[justinmk]

You can already do this via :unmap. And you can then opt-in by mapping things to e.g. vim.lsp.buf.rename(). These mappings are intentionally trivial mappings to vim.lsp.buf.* functions, which you can opt-in to by defining your own mappings to vim.lsp.buf.* functions.

Adding another random mechanism to selectively opt-in/opt-out is 100% redundant.

[justinmk]

I think distros like lazyvim, astrovim, nvchad, or whatever, which provide inner-platforms to "disable mappings" in a different way, are totally confusing people.

[KaspervdHeijden]

@justinmk I somewhat agree. I'm not using one such distro, but have a config based on an old fork of kickstart. This means I maintain my keymappings myself, and is part of the issue. The distros probably have such issues fixed ahead of time.