[Help] Key mapping - same key, different mode = different command
I'd like to add a single mapping that has slightly different commands in different modes. Specifically:
{
s = {'<cmd>lua require"gitsigns".stage_hunk()<CR>', "Stage hunk"},
s = {'<cmd>lua require"gitsigns".stage_hunk({vim.fn.line("."), vim.fn.line("v")})<CR>', "Stage lines", mode = 'v'}
}
Now obviously that will overwrite the key, so it's not valid - but what's the right way to achieve this result?
Have you tried running register twice?
running register twice works fine, that's what i ended up doing after running into this issue. i don't see it as a must-have but it's something more people will be running into in the future and should probably be documented in some way.
example: https://gitlab.com/gimerstedt/dotfiles/-/blob/master/nvim/lua/mappings/init.lua
Running register twice works.
A few notes:
- There are quirks. To get the mapping section "name" option to display for the second register, the mode has to be set on the entire register call. Setting mode on the individual bindings is fine if you don't want the name calls, though. Perhaps that's a broader bug that would appear for mixed-mapping-mode single-register-call configs?
- I do appreciate that they key mapping format is a nice data format, which helps me set up mappings that are consistent. Splitting the mappings into two register statements means I lose that for some keys.
I appreciate that 2 is an edge case, and 1 is easily solved, so I agree that a doc update would help most. Something like:
To map the same key to different commands in different modes, call register a second time with the mode option set. If you do not set the mode on the register call, some options (such as group names) may not work. For example:
wk.register({
['<leader>'] = {
g = {
name = "+ git",
s = {'<cmd>lua require"gitsigns".stage_hunk({vim.fn.line("."), vim.fn.line("v")})<CR>', "Stage lines"},
}
}
}, {mode = 'v'})
Hit this issue, too. This current behavior is pretty confusing and unexpected to me.
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.