Home row keys as modifiers is unusable with current implementation
I was trying the
dfk.home-row-modifiers.yaml given in the examples. This is an excellent idea. But, I found it unusable. This is a proposal on how to make it usable.
Example: Holding KEY_A for LEFT_SHIFT
Press and release
a within TAP_MILLIS (default 200ms) for
If press exceeds TAP_MILLIS, we get
<---------200ms---------> <---------200ms---------> keyboard: a↓ a↑ a↓ a↑ computer sees: a↓ a↑ LS↓ LS↑
If other keys are pressed in between press and release, how to handle it:
Typing the string
<---------200ms---------> <---------200ms---------> keyboard: a↓ s↓ a↑ s↑ computer sees: a↓a↑ s↓s↑
This is extremely important because the "smooth" touch typing experience comes from pressing the next key before releasing the current key. This gives that "gliding" motion from one key to the next. The current implementation is unusable for a touch typist. The current implementation will just ignore the inbetween keypress, as it is mentioned in the README:
Press or release another key during the TAP_MILLIS window and the tap will not occur.
This is especially useful for modifiers, for instance a quick ctrl-C. In this example we press the a key during the window.
The problem is that if you're using the homerow keys as modifiers, it is impossible to slow yourself down during typing as it will break your flow, but it is not a big problem to slow yourself down when hitting a shortcut, because you're most likely not going to press a series of shortcut after shortcut with a flow.
<---------200ms---------> <---------200ms---------> keyboard: a↓ s↓ s↑ (---a↑----) computer sees: LS↓ s↓s↑ (---LS↑---)
(---a↑----) is used to mean that the key
a can be released anywhere in that time range.
a, quickly followed by
<---------200ms---------> <---------200ms---------> keyboard: a↓ s↓ a↑ s↑ computer sees: a↓a↑ LC↓ LC↑