Custom <C-w>c mapping is ignored after timeout expires and falls back to built-in Quit action

[HarshK200]

Description

When overriding the built-in c mapping using vim.normalModeKeyBindingsNonRecursive, the custom mapping only works while the key sequence is entered within timeoutlen.

After timeoutlen expires, pressing c still triggers the built-in Quit action (c) and closes the editor, even though the built-in mapping has been overridden.

Steps to Reproduce

Configuration:

{
    "vim.timeout": 3000,
    "vim.normalModeKeyBindingsNonRecursive": [
        {
            "before": ["<C-w>", "c"],
            "commands": [
                "workbench.action.showCommands"
            ]
        }
    ]
}

1. Open a file.
2. Press Ctrl+w.
3. Wait less than timeoutlen.
4. Press c.

Result: The Command Palette opens (workbench.action.showCommands).

1. Press Ctrl+w.
2. Wait longer than timeoutlen.
3. Press c.

Result: The active editor is closed via the built-in c Quit action.

Expected Behavior
Once a built-in mapping has been overridden, the original action should never be executed.

After timeoutlen expires, one of the following would be expected:

The custom mapping still resolves.
The pending sequence is discarded.
The sequence is treated as unresolved and does nothing.

What should not happen is falling back to the original built-in c action that has already been overridden by a user mapping.

Additional Information

The behavior suggests that custom mappings and built-in actions are resolved through separate paths:

While the mapping timeout is active, the custom mapping takes precedence.
After the timeout expires, the built-in action becomes active again.

This effectively causes the original c binding to be restored after timeoutlen, which is surprising and makes overriding built-in commands unreliable.

I was able to trace the built-in action to the following registration:

keys = [
  ['<C-w>', 'q'],
  ['<C-w>', '<C-q>'],
  ['<C-w>', 'c'],
  ['<C-w>', '<C-c>'],
];

The custom mapping successfully overrides this action before timeout expiry, but not afterwards.

• Extension (VsCodeVim) version: v1.32.4
• VSCode version: 1.124.2
• OS: Window 11 Home

[hiSandog]

This sounds like the timeout path is falling back to the built-in second key handler after the user mapping prefix has already been recognized. A regression test should cover both timing branches with the same override: <C-w>c before timeoutlen runs the custom command, and <C-w> followed by waiting past timeoutlen must not leave c able to trigger the built-in close action. That would make the override contract independent of typing speed.