You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Input window insert-mode keybinds intermittently don't fire #332
I've been running into an issue where my keybinds like <M-m> (switch_mode) and <C-s> (submit_input_prompt) sometimes don't work when pressed in insert mode in the input window. Going back to normal mode and pressing the same key always works fine. The behavior is inconsistent — sometimes the key works in insert mode, sometimes it doesn't.
After digging into it, I think the issue is related to how wrap_with_completion_check works in keymap.lua. Right now, when input window keymaps are registered, setup_window_keymaps is called with defer_to_completion=true, which wraps every input window keymap with the completion visibility check. There is also a similar behavior in the input_window.lua in handle_submit() function.
This wrapping makes sense for keys that could genuinely conflict with completion navigation (like <CR>, <Tab>), but this is not my case and makes it a more painful experience. Basically, there isn't any situation where I would not want <M-m> or <C-s> to do the actions configured.
Feature request:
It would be nice to have a way to control this on a per-keybinding basis and perhaps also globally (i.e. bypass any completion or similar check and ensure keybind does the configured behavior)
sure. Just to be sure I understand, would that mean that the default behavior becomes: keybinds no longer check if completion menu is visible, they always work, unless specified in "a config to set which mappings you want to sent to the completion"
I would do it in reverse actually, as it would be a breaking change. If the list is empty it will always do the call to defer_to_completion if you provide a list of keys it will use it.
EDIT:
Or even a flag in the keymap itself to defer to completion
@sudo-tee seems to work well so far for non-submit keybinds, although the handle_submit() function I believe is unmodified and still checks for completion being visible, no matter what. In my case, it does not send the keybind currently.
Activity
sudo-tee commentedon Mar 18, 2026
Would a config to set which mappings you want to sent to the completion work for you ?
jemag commentedon Mar 18, 2026
sure. Just to be sure I understand, would that mean that the default behavior becomes: keybinds no longer check if completion menu is visible, they always work, unless specified in
"a config to set which mappings you want to sent to the completion"sudo-tee commentedon Mar 19, 2026
I would do it in reverse actually, as it would be a breaking change. If the list is empty it will always do the call to
defer_to_completionif you provide a list of keys it will use it.EDIT:
Or even a flag in the keymap itself to defer to completion
feat(keymap): defer keymaps to completion menu
feat(keymap): defer keymaps to completion menu
sudo-tee commentedon Mar 19, 2026
@jemag
I created a PR for this, #334
Let me know if it works for you
jemag commentedon Mar 19, 2026
@sudo-tee seems to work well so far for non-submit keybinds, although the
handle_submit()function I believe is unmodified and still checks for completion being visible, no matter what. In my case, it does not send the keybind currently.sudo-tee commentedon Mar 20, 2026
@jemag
I removed the check in handle_submit. Let me know if it works for you.
jemag commentedon Mar 20, 2026
working great so far with the new changes, thanks!
sudo-tee commentedon Mar 20, 2026
Great I will merge this :)
feat(keymap): defer keymaps to completion menu (#334)
feat(keymap): defer keymaps to completion menu (sudo-tee#334)