What exactly changed in nvim_get_keymap()

Neovim
1

Now there’s no rhs instead a callback causing some issues in plugins like which-key

Why did nvim_set_keymap() changed and vim.keymap.set() didn’t?

I found that weird

I think that differentiation between rhs and callback adds unecessary complexity

2

Why did nvim_set_keymap() changed and vim.keymap.set() didn’t?

Not sure what you mean. vim.keymap.set() was introduced after support for callback was added to nvim_set_keymap. So vim.keymap.set() didn’t change, it’s totally new.

The distinction between rhs and callback in nvim_set_keymap was necessary because it can be called over rpc. So the type of rhs was kept the same (string) and a callback key was added to the options table, which is only usable inside lua script (not over rpc).

which-key just needs a small update (a couple of PRs are already open) to fix the issue.

3

I understand but to me it does not make sense the following:

-- vim.keymap.set({mode}, {lhs}, {rhs}, {opts})

vim.keymap.set(
  "n", -- mode
  "asdf", -- lhs

  function() -- rhs
    print('Hello') -- rhs
  end, -- rhs

  {} -- opts
)

and then when I want to get the mappings:

vim.api.nvim_get_keymap("n")

-- { lhs = "asdf", callback = "<function 1>", ... } -- no rhs

Maybe we should create a vim.keymap.get() to make that a little bit more understandable

5

Ah yes. Having a vim.keymap.get that keeps it similar to vim.keymap.set would be nice.

Just as nvim_get_keymap keeps it similar to nvim_set_keymap.

6

Let me reiterate that: the use of callback for native Lua function mappings is very much necessary complexity; it couldn’t have been done any other (better) way – hence the more convenient vim.keymap API on top of it.

A reasoned PR (explaining the rationale) introducing vim.keymap.get would be well-received, though.

1 Like