`:Copilot disable` throws `E31: No such mapping` when using `Alt` keymaps

[samuelborn]

Summary
E31: No such mapping occurs on :Copilot disable if suggestion.keymap.accept uses Alt/Meta (<M-…>/<A-…>). Using e.g. Control (<C-…>) avoids the error.

Environment

• OS: Fedora 48
• Neovim: NVIM v0.11.3
• node: on PATH (verified as suggested by this comment)

Steps to Reproduce

1. Save as repro.lua, run nvim -u repro.lua.
2. :Copilot disable.

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
  spec = {
    "zbirenbaum/copilot.lua",
    opts = {
      suggestion = {
        keymap = {
          accept = "<M-CR>"        -- does not work
          -- accept = "<M-Enter>"  -- does not work
          -- accept = "<A-CR>"     -- does not work
          -- accept = "<A-Enter>"  -- does not work
          -- accept = "<C-CR>"     -- Control keymap works
        }
      },
    },
  },
})

Expected
Disables cleanly regardless of chosen modifier.

Actual
With any Alt/Meta mapping above:

Error executing Lua callback: vim/keymap.lua:0: E31: No such mapping                                                                                                                            
stack traceback:                                                                                                                                                                                
        [C]: in function 'nvim_del_keymap'                                                                                                                                                      
        vim/keymap.lua: in function 'del'                                                                                                                                                       
        ...re/nvim/lazy/copilot.lua/lua/copilot/suggestion/init.lua:183: in function 'unset_keymap'                                                                                             
        ...re/nvim/lazy/copilot.lua/lua/copilot/suggestion/init.lua:863: in function 'teardown'                                                                                                 
        ...ocal/share/nvim/lazy/copilot.lua/lua/copilot/command.lua:80: in function <...ocal/share/nvim/lazy/copilot.lua/lua/copilot/command.lua:76>                                            
        ...rn/.local/share/nvim/lazy/copilot.lua/plugin/copilot.lua:41: in function <...rn/.local/share/nvim/lazy/copilot.lua/plugin/copilot.lua:9>   

Replacing with a Control mapping (e.g., <C-CR>) makes :Copilot disable succeed.

[AntoineGS]

Are you able to trigger the accept action with these keymaps?
It seems to me that they are not being registered for some reason so when it comes to unregistering them it fails.

Edit: I tried getting completion to work with the above keys and none are working for me, not sure if it is due to my terminal hijacking the keys or not, but using Alt and Meta work fine with regular keys.
<M-p> for example works fine.

[samuelborn]

Yes the keybinds themselves work. Including keybinds with Alt.

[AntoineGS]

Ah I think I've figured it out, M-CR is already being set by the panel keymaps, hence the panel will unregister it and when the suggestion tries to as well it fails as it is already gone. Changing the default keymaps of the panel resolves it (you can set them all to false).
A-CR seems to clash with the CR keymap so the above will also resolve it.

[samuelborn]

Yep that was it! I verified that issue does not occur with the following miminal config.

vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()

require("lazy.minit").repro({
    spec = {
        "zbirenbaum/copilot.lua",
        opts = {
            panel = {
                keymap = {
                    open = false
                }
            },
            suggestion = {
                keymap = {
                    accept = "<M-CR>"
                },
            },
        },
    },
})

I think though it would be nicer if the plugin should handle it without an error even without me unsetting the keybind manually.

[AntoineGS]

Yeah I've been thinking about what to do if a conflict happens.
While in your case the keymap that was active ended up being the one you wanted (suggestion), it may not be the case for all users.
I was thinking of adding a keymap validation to the :checkhealth command which would let the user know there is a conflict.
Alternatively the plugin could give precedence to the keymap that was manually configured, but that would add a lot of generally useless validations (when configs are OK) every time the plugin loads.