Closed tdy closed 5 years ago
Sorry, I meant to cancel my followup reply but hit "close and comment" accidentally.
Interesting. I did some tests and this behaviour does seem consistent with the rest of the modifier keys. Pressing Ctrl+Z in quick succession so that there is a tiny overlap results in the undo command being issued.
My concern with adding a configurable delay is: there might not be a number that feels good across all situations. For example (assuming the default remappings): Imagine a user presses CAPSLOCK then C very quickly, resulting in the two key presses overlapping briefly. Did the user intend to send CTRL+C or CTRL and C separately?
In some cases it will be the former; in others it will be the latter. I don't see a way that dual-key-remap could distinguish between the two reliably, so I would rather the utility would stay consistent with how the rest of the modifier keys behave.
That said, I'm open to other suggestions.
A similar problem was referenced in #11. I think the best way of handling this is to only trigger the with_other
modifier when another key is pressed down while holding the modifier (as opposed to when any key is pressed both up or down). This is implemented in the latest release (v0.4).
This is a common sequence in my workflow: ESC + release ESC + another key. It comes up a lot in vim, bash, etc.
The problem is when I do these keystrokes quickly, a lot of times I haven't 100% released ESC before hitting the next key. This causes dual-key-remap to register it as a CTRL modifier instead.
Apart from the physical workaround of typing slower to make sure I fully release ESC every time, is there a programmatic way to handle this? Maybe a configurable millisecond delay when checking
remappedKeyState
or something?