Turning off default nvf keymaps

[kalyanoliveira]

The README says:

There are almost no defaults to annoy you.

And, yet, this is the third time that I'm annoyed by defaults :D.

The first was #746.

Then with blink-cmp.

And now, after vim.lsp.enable = true and [user@hostname:~]$ nvf-print-config, I find that there are a bunch of LSP-related default keymaps that I don't want:

-- Excerpt of output of `[user@hostname:~]$ nvf-print-config`
local attach_keymaps = function(client, bufnr)
  vim.keymap.set('n', '<leader>lgD', vim.lsp.buf.declaration, {buffer=bufnr, noremap=true, silent=true, desc='Go to declaration'})
  vim.keymap.set('n', '<leader>lgd', vim.lsp.buf.definition, {buffer=bufnr, noremap=true, silent=true, desc='Go to definition'})
  vim.keymap.set('n', '<leader>lgt', vim.lsp.buf.type_definition, {buffer=bufnr, noremap=true, silent=true, desc='Go to type'})
  vim.keymap.set('n', '<leader>lgi', vim.lsp.buf.implementation, {buffer=bufnr, noremap=true, silent=true, desc='List implementations'})
  vim.keymap.set('n', '<leader>lgr', vim.lsp.buf.references, {buffer=bufnr, noremap=true, silent=true, desc='List references'})
  vim.keymap.set('n', '<leader>lgn', vim.diagnostic.goto_next, {buffer=bufnr, noremap=true, silent=true, desc='Go to next diagnostic'})
  vim.keymap.set('n', '<leader>lgp', vim.diagnostic.goto_prev, {buffer=bufnr, noremap=true, silent=true, desc='Go to previous diagnostic'})
  vim.keymap.set('n', '<leader>le', vim.diagnostic.open_float, {buffer=bufnr, noremap=true, silent=true, desc='Open diagnostic float'})
  vim.keymap.set('n', '<leader>lH', vim.lsp.buf.document_highlight, {buffer=bufnr, noremap=true, silent=true, desc='Document highlight'})
  vim.keymap.set('n', '<leader>lS', vim.lsp.buf.document_symbol, {buffer=bufnr, noremap=true, silent=true, desc='List document symbols'})
  vim.keymap.set('n', '<leader>lwa', vim.lsp.buf.add_workspace_folder, {buffer=bufnr, noremap=true, silent=true, desc='Add workspace folder'})
  vim.keymap.set('n', '<leader>lwr', vim.lsp.buf.remove_workspace_folder, {buffer=bufnr, noremap=true, silent=true, desc='Remove workspace folder'})
  vim.keymap.set('n', '<leader>lwl', function() vim.notify(vim.inspect(vim.lsp.buf.list_workspace_folders())) end, {buffer=bufnr, noremap=true, silent=true, desc='List workspace folders'})
  vim.keymap.set('n', '<leader>lws', vim.lsp.buf.workspace_symbol, {buffer=bufnr, noremap=true, silent=true, desc='List workspace symbols'})
  vim.keymap.set('n', '<leader>lh', vim.lsp.buf.hover, {buffer=bufnr, noremap=true, silent=true, desc='Trigger hover'})
  vim.keymap.set('n', '<leader>ls', vim.lsp.buf.signature_help, {buffer=bufnr, noremap=true, silent=true, desc='Signature help'})
  vim.keymap.set('n', '<leader>ln', vim.lsp.buf.rename, {buffer=bufnr, noremap=true, silent=true, desc='Rename symbol'})
  vim.keymap.set('n', '<leader>la', vim.lsp.buf.code_action, {buffer=bufnr, noremap=true, silent=true, desc='Code action'})
  vim.keymap.set('n', '<leader>lf', vim.lsp.buf.format, {buffer=bufnr, noremap=true, silent=true, desc='Format'})
  vim.keymap.set('n', '<leader>ltf', function() vim.b.disableFormatSave = not vim.b.disableFormatSave end, {buffer=bufnr, noremap=true, silent=true, desc='Toggle format on save'})
end

How can I easily turn them all off? That way I would not be annoyed by turning each and every single one of them off :D.

[KennethHoff]

Would be nice if, at the very least, lsp used the default bindings introduced in (0.11? 0.10?). I think nvf should be as default as possible

[jules-sommer]

I have also been annoyed by the dual occurrences of key binds in setupOpts.keymaps, or something of the like within setupOpts, which is provided by the plugin and configured through lua generated via toLuaObject, and then also you have the option provided by nvf @ {plugin}.mappings which is very tedious to disable due to needing to set them all null, and they're created by default and it seems that disabling them at all was an afterthought since setting them to null isn't checked for anywhere AFAIK and it just causes toLuaObject to not omit it, i.e:

nix-repl> lib.nvim.lua.toLuaObject { something = null; }
"{}"

and in the nvf/modules/plugins/lsp/config.nix you can see how it's assumed you will both use this source of mappings and that they wont be null:

pluginRC.lsp-setup = ''
  local attach_keymaps = function(client, bufnr)
    ${mkBinding mappings.goToDeclaration "vim.lsp.buf.declaration"}
    ${mkBinding mappings.goToDefinition "vim.lsp.buf.definition"}
    ${mkBinding mappings.goToType "vim.lsp.buf.type_definition"}
    ${mkBinding mappings.listImplementations "vim.lsp.buf.implementation"}
    ${mkBinding mappings.listReferences "vim.lsp.buf.references"}
    ${mkBinding mappings.nextDiagnostic "vim.diagnostic.goto_next"}
    ${mkBinding mappings.previousDiagnostic "vim.diagnostic.goto_prev"}
    ${mkBinding mappings.openDiagnosticFloat "vim.diagnostic.open_float"}
    ${mkBinding mappings.documentHighlight "vim.lsp.buf.document_highlight"}
    ${mkBinding mappings.listDocumentSymbols "vim.lsp.buf.document_symbol"}
    ${mkBinding mappings.addWorkspaceFolder "vim.lsp.buf.add_workspace_folder"}
    ${mkBinding mappings.removeWorkspaceFolder "vim.lsp.buf.remove_workspace_folder"}
    ${mkBinding mappings.listWorkspaceFolders "function() vim.notify(vim.inspect(vim.lsp.buf.list_workspace_folders())) end"}
    ${mkBinding mappings.listWorkspaceSymbols "vim.lsp.buf.workspace_symbol"}
    ${mkBinding mappings.hover "vim.lsp.buf.hover"}
    ${mkBinding mappings.signatureHelp "vim.lsp.buf.signature_help"}
    ${mkBinding mappings.renameSymbol "vim.lsp.buf.rename"}
    ${mkBinding mappings.codeAction "vim.lsp.buf.code_action"}
    ${mkBinding mappings.format "vim.lsp.buf.format"}
    ${mkBinding mappings.toggleFormatOnSave "function() vim.b.disableFormatSave = not vim.b.disableFormatSave end"}
  end
'';

and these key binds, unless you know to look for them, are the ones that appear seemingly out of nowhere just via enabling plugins.

I think that is the source of most of the unexpected keybindings.

anywayyyyyssss I promise I didn't just reply here to complain XD

I am willing to write a PR to start working on improving and organizing this keybindings issue, and maybe implement a better mechanism or a different way of handling plugin keybinds if we come up with anything like that. But I basically wanted to reply here to start a conversation ab this and maybe figure out what direction to take and get some ideas going because on my own starting a PR for this seems daunting not in difficulty of the problem but in terms of knowing that my personal ideal solution is probably not what works best for all users of nvf or also the maintainers and so I guess I want to get some clarity before I go making drastic changes.

@NotAShelf I hope it isn't considered a faux pas to ping u like this but I know you would have some thoughts and I definitely want your opinion before I attempt anything like this. or if it's even something I should attempt at all since maybe someone else or yourself is working on something to a similar end or whatever it may be. <3

[jules-sommer]

Also as a temporary workaround, you can use this to easily set them all to null for a given ${plugin}.mappings:

vim.lsp.mappings = lib.mapAttrs (_: _: null) config.vim.lsp.mappings;

this is what I am doing in the instance that I ran into this problem in my own config.

[kalyanoliveira]

I have been looking for something like this, thanks! Then ig you could just put some lib.mkForce to get the keymappings that you actually want.

[kalyanoliveira]

Not sure if it should be marked as an answer though; wouldn't we ideally be looking for some built-in implementation of this?

[jules-sommer]

Not sure if it should be marked as an answer though; wouldn't we ideally be looking for some built-in implementation of this?

yay im glad it works for you! I think if you want to disable all mappings regardless of location, i.e not just vim.lsp.mappings but all vim.*.mappings I can quickly write a snippet for that too.

as for a builtin implementation, I would love to work on a PR for it, but I need to get some more input from @NotAShelf and anyone else who has thoughts on what an ideal implementation for improving keybinds for plugins would look like, and then we'll need to generally work out a plan, which will take some time but is ultimately pretty achievable. Idk if marking as answered will close this thread for discussion, because if it does then I think we should keep it open to talk about how that implementation would look.

I have been looking for something like this, thanks! Then ig you could just put some lib.mkForce to get the keymappings that you actually want.

im not even sure you would need lib.mkForce, it can be set by you in your own config to the desired values without that. Just as I wrote it, it works

[NotAShelf]

Sorry for the late response, it's one of those times that I formulate a reply in my mind, fool myself by thinking I sent it, and then forget about the reply amidst the chaos of everything going on. The LSP related keybinds are a relic from an earlier version of nvf, which is when it was closer to the project it was forked from. In v0.6 the keybind system was improved, but some things were left over. Although I would love for a keybind system that doesn't suck, it is currently one of the weak links that I am hoping to change. It is just that the current release focuses on the API changes in 0.8 and better structuring the language module system that was yet another weak link.

Also as a temporary workaround, you can use this to easily set them all to null for a given ${plugin}.mappings:

vim.lsp.mappings = lib.mapAttrs (_: _: null) config.vim.lsp.mappings;

this is what I am doing in the instance that I ran into this problem in my own config.

This is one of the ways you can do it, but it's a workaround and a hack rather than a real solution. A PR was opened but we agreed to continue at a later with a more robust solution. Due to time constraints, it was postponed for the time being.

I am willing to write a PR to start working on improving and organizing this keybindings issue, and maybe implement a better mechanism or a different way of handling plugin keybinds if we come up with anything like that. But I basically wanted to reply here to start a conversation ab this and maybe figure out what direction to take and get some ideas going because on my own starting a PR for this seems daunting not in difficulty of the problem but in terms of knowing that my personal ideal solution is probably not what works best for all users of nvf or also the maintainers and so I guess I want to get some clarity before I go making drastic changes.

A PR would be very welcome. We're currently in a tight position for the v0.8 release (alongside similar release windows for other projects that I maintain) so most of my free time goes to ensuring the active releases go smoothly. If you would like to propose a system, I'm sure we can discuss it altogether with maintainers and users previously annoyed by the current mechanism.

@NotAShelf I hope it isn't considered a faux pas to ping u like this but I know you would have some thoughts and I definitely want your opinion before I attempt anything like this. or if it's even something I should attempt at all since maybe someone else or yourself is working on something to a similar end or whatever it may be. <3

You are welcome to ping me any time. You are invited even, because I sometimes don't get notified of incoming issues/PRs at all or I tend to forget. In short please feel free to ping me.

[jules-sommer]

Sorry for the late response, it's one of those times that I formulate a reply in my mind, fool myself by thinking I sent it, and then forget about the reply amidst the chaos of everything going on. The LSP related keybinds are a relic from an earlier version of nvf, which is when it was closer to the project it was forked from. In v0.6 the keybind system was improved, but some things were left over. Although I would love for a keybind system that doesn't suck, it is currently one of the weak links that I am hoping to change. It is just that the current release focuses on the API changes in 0.8 and better structuring the language module system that was yet another weak link.

Also as a temporary workaround, you can use this to easily set them all to null for a given ${plugin}.mappings:

vim.lsp.mappings = lib.mapAttrs (_: _: null) config.vim.lsp.mappings;

this is what I am doing in the instance that I ran into this problem in my own config.

This is one of the ways you can do it, but it's a workaround rather than a hack. A PR was opened but we agreed to continue at a later with a more robust solution. Due to time constraints, it was postponed for the time being.

I am willing to write a PR to start working on improving and organizing this keybindings issue, and maybe implement a better mechanism or a different way of handling plugin keybinds if we come up with anything like that. But I basically wanted to reply here to start a conversation ab this and maybe figure out what direction to take and get some ideas going because on my own starting a PR for this seems daunting not in difficulty of the problem but in terms of knowing that my personal ideal solution is probably not what works best for all users of nvf or also the maintainers and so I guess I want to get some clarity before I go making drastic changes.

A PR would be very welcome. We're currently in a tight position for the v0.8 release (alongside similar release windows for other projects that I maintain) so most of my free time goes to ensuring the active releases go smoothly. If you would like to propose a system, I'm sure we can discuss it altogether with maintainers and users previously annoyed by the current mechanism.

@NotAShelf I hope it isn't considered a faux pas to ping u like this but I know you would have some thoughts and I definitely want your opinion before I attempt anything like this. or if it's even something I should attempt at all since maybe someone else or yourself is working on something to a similar end or whatever it may be. <3

You are welcome to ping me any time. You are invited even, because I sometimes don't get notified of incoming issues/PRs at all or I tend to forget. In short please feel free to ping me.

okay cool! I will mess around with it then when I have some time and see what I come up with!

[snoweuph]

+1 to this.

I personally really struggle with configuring my bindings in nvf, due to there being so many things registered under <leader>.

In my old configs, I always had one lua table for all my bindings under <leader> + which key.
https://git.euph.dev/snoweuph/nvimrc/src/commit/5294be6784940bb97fa710cf924c3392cb0ad9aa/lua/core/key_map.lua

having it full of so many things I don't want, really is a lot of extra config work, especially as even with:

vim.lsp.mappings = lib.mapAttrs (_: _: null) config.vim.lsp.mappings;

I would still need to find for all the plugins and everything where their mapping is configured.
would be awesome to have an option or a simple way to clear all default bindings that start with <leader>.

now that I'm writing this, I guess I could just do that with some custom startup lua, but that of course would also bee less in the spirit of nvf and nix in general.

I personally think a big problem of the current approach is, that the key map is not 100% centralized.
If I change any keybindings, I wanna see the config of all my keybindings, so I can be sure I don't create conflicts and as to see the bigger picture of groups and stuff, which generally help me remembering my bindings.