Description
When setting accept_word inside suggestion.keymap via lazy.nvim's opts (or LazyVim's default opts merge), the key mapping is never created. However, if I use the config function to directly call require("copilot").setup({...}) with the exact same configuration, the mapping works perfectly. Other keymaps like accept, next, prev are correctly registered under the same opts table. The underlying function require("copilot.suggestion").accept_word() works fine when called directly.
Steps to Reproduce
Method A (fails): Using opts
{
"zbirenbaum/copilot.lua",
cmd = "Copilot",
event = "InsertEnter",
opts = {
suggestion = {
enabled = true,
auto_trigger = true,
keymap = {
accept_word = "<M-w>", -- also tried single char "w", ";"
accept = false,
next = "<M-]>",
prev = "<M-[>",
},
},
},
}
After this configuration, press <M-w> while a suggestion is visible → nothing happens. :verbose imap <M-w> shows No mapping found.
Method B (works): Using config function
{
"zbirenbaum/copilot.lua",
cmd = "Copilot",
event = "InsertEnter",
config = function()
require("copilot").setup({
suggestion = {
enabled = true,
auto_trigger = true,
keymap = {
accept_word = "<M-w>",
accept = false,
next = "<M-]>",
prev = "<M-[>",
},
},
})
end,
}
After this configuration, pressing <M-w> while a suggestion is visible correctly accepts the first word. :verbose imap <M-w> shows the mapping.
Expected Behavior
Both opts and config approaches should produce the same result: the accept_word keymap should be registered.
Actual Behavior
Only the config approach works. The opts approach fails to register the accept_word mapping, while other keymaps (accept, next, prev) work fine in both approaches.
Additional Observations
- Calling
require("copilot.suggestion").accept_word() directly (e.g., via :lua) works correctly – the function itself is not broken.
- The issue is specifically about keymap registration when using
opts. It seems the accept_word entry in the keymap table is silently ignored during the setup process when configuration comes from merged opts.
- Using a single character (
"w", ";") instead of a modifier combination ("<M-w>") also fails in the opts approach.
Environment
- Neovim version: 0.11.0+
- Plugin manager: lazy.nvim (also tested with LazyVim distribution)
copilot.lua version: latest (commit d521d39 as of testing)
- OS: Linux / macOS
Possible Cause
The difference between opts and config suggests that lazy.nvim's opts merging process may alter the keymap table in a way that causes accept_word to be dropped or not recognized by copilot.lua's internal setup. Alternatively, copilot.lua's handling of keymap may have a condition that only applies when the table comes from certain sources.
Workaround
Use config function to call require("copilot").setup(...) directly – this is the reliable way to configure accept_word.
Description
When setting
accept_wordinsidesuggestion.keymapvia lazy.nvim'sopts(or LazyVim's default opts merge), the key mapping is never created. However, if I use theconfigfunction to directly callrequire("copilot").setup({...})with the exact same configuration, the mapping works perfectly. Other keymaps likeaccept,next,prevare correctly registered under the sameoptstable. The underlying functionrequire("copilot.suggestion").accept_word()works fine when called directly.Steps to Reproduce
Method A (fails): Using
opts{ "zbirenbaum/copilot.lua", cmd = "Copilot", event = "InsertEnter", opts = { suggestion = { enabled = true, auto_trigger = true, keymap = { accept_word = "<M-w>", -- also tried single char "w", ";" accept = false, next = "<M-]>", prev = "<M-[>", }, }, }, }After this configuration, press
<M-w>while a suggestion is visible → nothing happens.:verbose imap <M-w>showsNo mapping found.Method B (works): Using
configfunction{ "zbirenbaum/copilot.lua", cmd = "Copilot", event = "InsertEnter", config = function() require("copilot").setup({ suggestion = { enabled = true, auto_trigger = true, keymap = { accept_word = "<M-w>", accept = false, next = "<M-]>", prev = "<M-[>", }, }, }) end, }After this configuration, pressing
<M-w>while a suggestion is visible correctly accepts the first word.:verbose imap <M-w>shows the mapping.Expected Behavior
Both
optsandconfigapproaches should produce the same result: theaccept_wordkeymap should be registered.Actual Behavior
Only the
configapproach works. Theoptsapproach fails to register theaccept_wordmapping, while other keymaps (accept,next,prev) work fine in both approaches.Additional Observations
require("copilot.suggestion").accept_word()directly (e.g., via:lua) works correctly – the function itself is not broken.opts. It seems theaccept_wordentry in thekeymaptable is silently ignored during the setup process when configuration comes from mergedopts."w",";") instead of a modifier combination ("<M-w>") also fails in theoptsapproach.Environment
copilot.luaversion: latest (commit d521d39 as of testing)Possible Cause
The difference between
optsandconfigsuggests that lazy.nvim'soptsmerging process may alter thekeymaptable in a way that causesaccept_wordto be dropped or not recognized by copilot.lua's internal setup. Alternatively, copilot.lua's handling ofkeymapmay have a condition that only applies when the table comes from certain sources.Workaround
Use
configfunction to callrequire("copilot").setup(...)directly – this is the reliable way to configureaccept_word.