VIM: Incorrect behavior of <key + shift + key> in Ubuntu 20.04

[serpro69]

Hi,
I’m having an issue where <key + shift + key> results in an incorrect behavior.

For example, if I try to jump to next occurrence of “D” on current line with <f + D> the actual result will delete the entire line (as if I only used <shift + d> without ).
Or, for example, if I try to jump the next occurrence of “I” on the same line with <f + I> the actual result will switch to insert mode and move the cursor to beginning of the line (<shift + shift i> behavior).

At the same time backward search with <F + D> or <F + I> works fine.

The above are just a couple of examples. The same happens, when I, for example, try to replace a single char with some capital letter that has a special meaning, i.e. <r + D> will just delete the line, or replacing a char with { will jump to previous paragraph, and so on.

I’m experiencing this in another app that uses codemirror as an editor - Joplin (and I’ve also tried Obsidian, I believe they also use codemirror for editing files, and it has the same issue) - so I’m not 100% sure how to reproduce this with just codemirror. But I have tried it on the demo page (https://codemirror.net/demo/vim.html) and I see the same behavior there as well.

I’ve tried to record the issue using the above demo page. Hope it’s clear from the recording - I try to jump to different upper case chars with <f + CHAR> but instead a different action is executed.

[marijn]

The vim mode doesn’t currently have a maintainer. You can still try filing an issue on github— thoseare occasionally addressed by contributors.

[serpro69]

Thanks @marijn, I’ll post an issue on github.
Strange thing is, I can reproduce it in Brave browser, as well as some apps that are using codemirror (Joplin, Obsidian), but it works just find in Firefox…

[benhormann]

I had a close look at your gif. There appears to be a delay between the Key buffer clearing (the f disappears, changes to normal mode), and the action (deleting the line, changing to insert mode, etc.). It should be immediate, but it doesn’t look that way.

@serpro69 Can you try it again while recording a macro?
Press q and then any letter (i.e. choose a register) to record into, press q again to stop. Then paste it on an empty line (e.g. "xp where x is your register).

Or open devtools (F12) and put a breakpoint in vim.html, line 109. It helps to add a condition to the breakpoint: keys === '' && commandDisplay.innerHTML !== ''
If you don’t see something like “Key buffer: fD”, enter event into the console (or add a watch expression) so you can find out what the key/event is.

[serpro69]

Hi @benhormann and thanks a lot for taking a look at this!

Here’s the output of the recorded macro in Brave browser where the issue can be reproduced: f<S-CapsLock><CapsLock>D, and this looks kind of weird.
But in firefox, where the functionality works fine, the output is just fD
Do you want me to do the second part as well with the breakpoint?

[benhormann]

No need, the problem is Caps Lock. I normally have caps lock disabled but I can simulate the effect, even in Firefox.

@serpro69 Are you actually using the Caps Lock key, or some kind of keyboard software (e.g. AutoKey or QMK firmware)?
It is weird that it is not happening in Firefox too.

[serpro69]

I am using Caps key - I have it remapped to Ctrl, and then both L-Shift and R-Shift enable Caps Lock. But I also think it’s disabled by default. Maybe that’s the issue here. Thanks a lot for the pointers, I’ll try to dig into this further and see how I can fix this.

Yes, indeed it’s strange that it’s not happening in Firefox, and that’s what threw me off originally.