“c” behaves strangely when swapped with “h”

[ejpcmac]

Describe the bug

In order to be comfortable with the BÉPO keyboard layout, I have swapped hjkl and ctsr. Since VSCodeVim 1.21.0, there is some delay between the moment c is pressed and the cursor effectively moving to the left. If I press it multiple times in a row, it seems to move, but there is still a one-second delay before it is at its “real” position.

To Reproduce
Steps to reproduce the behavior:

1. Add this configuration:

   "vim.normalModeKeyBindingsNonRecursive": [
       { "before": ["c"], "after": ["h"] },
       { "before": ["t"], "after": ["j"] },
       { "before": ["s"], "after": ["k"] },
       { "before": ["r"], "after": ["l"] },
   ],

2. Position the cursor so it has some space on its left.

3. Type c and see the cursor having a one-second delay.

Expected behavior

Like for t, s and r, and even c in previous versions, there should be no delay.

Screenshots

[Extension Host] ModeHandler: debug: handling key=c.
[Extension Host] Remapper: debug: trying to find matching remap. keys=c. mode=Normal. keybindings=normalModeKeyBindingsMap.
[Extension Host] Remapper: verbose: key=c. keySlice=c.
[Extension Host] Remapper: debug: normalModeKeyBindingsMap. ambiguous match found. before=c. after=h. command=undefined. waiting for other key or timeout to finish.
[Extension Host] ModeHandler: debug: handleKeyEvent('c') took 2ms
[Extension Host] ModeHandler: debug: handling key=<timeoutfinished>.
[Extension Host] Remapper: debug: trying to find matching remap. keys=c. mode=Normal. keybindings=normalModeKeyBindingsMap.
[Extension Host] Remapper: verbose: key=c. keySlice=c.
[Extension Host] Remapper: debug: normalModeKeyBindingsMap. match found. before=c. after=h,<TimeoutFinished>. command=undefined. remainingKeys=. mapDepth=1.
[Extension Host] ModeHandler: debug: handling key=h.
[Extension Host] ModeHandler: debug: Selections: Adding Selection Change to be Ignored! Hash: [25, 23; 25, 23], Selections: [25, 23], [25, 23]
[Extension Host] ModeHandler: debug: handleKeyEvent('h') took 6ms
[Extension Host] ModeHandler: debug: handling key=<timeoutfinished>.
[Extension Host] ModeHandler: debug: handleKeyEvent('<timeoutfinished>') took 0ms
[Extension Host] ModeHandler: debug: handleKeyEvent('<timeoutfinished>') took 8ms
[Extension Host] Extension Startup: debug: Selections: Ignoring selection: [25, 23; 25, 23], Count left: 0

=> It seems there is some ambiguity, but I’ve defined the remap only once, so this is very strange.

Environment (please complete the following information):

• Extension (VsCodeVim) version: 1.21.3, 1.21.2, 1.21.1, 1.21.0
• VSCode version: 1.56.2 (but also on latest on my work PC)
• OS: NixOS 21.05, Windows 10

[sql-koala]

Here, #6452 we created a default map on "cs" to an internal sequence.
I am quite sure that's it.

try adding this to vimrc:

nunmap cs
nnoremap ?? <plugcs>

where ?? is what you want to use for change surround.

[johanrosenkilde]

I have the equivalent issue but with ys/yss (since I'm using the Workman keyboard layout, where y is on the h-key).

I was unable to find a combination of unmaps which would remove the waiting-for-next-key behaviour on y. Perhaps it is complicated by having to disable both ys and yss, though obviously I tried that as well.

As a depressing work-around I've now disabled vim.surround. That removes the problem. Any help is much appreciated.

[sql-koala]

apparently, it is not possible to unmap from vimrc what was loaded at the stage for settings.json (that's when cs, ys are mapped).

technically, we could create a setting like "vim.disableDefaultPluginMappings" with false as default and check for that.

[johanrosenkilde]

Thanks for looking into this!

apparently, it is not possible to unmap from vimrc what was loaded at the stage for settings.json (that's when cs, ys are mapped).

Is there some way to read user settings after surround's key mappings? Then the user could use settings.json to remove cs,ys again if they needed to?

technically, we could create a setting like "vim.disableDefaultPluginMappings" with false as default and check for that.

As you write in your code comment on #6860, most users with custom keyboard layouts need to set many shortcuts anew anyway, but it still seems pretty coarse that we can only enable/disable all plugin mappings at a time :-/

[sql-koala]

... but it still seems pretty coarse that we can only enable/disable all plugin mappings at a time :-/

This will affect only a few mappings, that share "keyspace" with existing operators: c/d/y.
Right now: only surround. Possibly in the future, if done: exchange cx, coerce cr.

All other existing plugins are unaffected.

[hadronized]

I reproduce as well the c issue with the remapping in bépo.

[mrtolkien]

Same issue here a few years later with the Dvorak layout trying to remap y somewhere else. Would be really nice to see this bug fixed!

[pcwa-ahendricks]

Can the defaults specified in src/actions/plugins/pluginDefaultMappings.ts be unset in user settings in any way?

[pcwa-ahendricks]

Oh I see, there is a pull request already that would fix this issue, but maintainers are not interested in pulling it; that's unfortunate.

[ianfromdover]

The (interim) fix: map yy to u so that you do not have to wait for the timeout. You may do the same for any other key that times out.

nnoremap yy u " remaps yy to u (undo) non-recursively in normal mode

Replace yy with cc or dd as needed. Hope this helps. I'm using the Gallium layout.

[qdii]

How is that pull request doing a year and a half later?