The "closest key" logic must be careful not to reveal keys removed by a
modifier.
Must check [_handler.onPointerSwipe] for every candidate values.
[selected_value] is changed back to [selected_direction].
This adds a new bug: When the direction change, the selected value might
not change but a vibration will be triggered anyway.
getAtDirection was too hard to maintain and might contain bugs.
Change slightly the meaning of directions and implement a the nearest
key calculation as a loop.
When typing fast, a second key might be pressed before the first is
released.
Clearing modifiers earlier would prevent this but would break modifiers
placed in corners (especially the accent keys). Instead, don't take
latched modifiers into account when registering the second press.
A new flag is needed to not interfere with holding modifers, which is
merged with the norepeat flag.
Modifiers can temporarily remove a key from the layout by returning
'null'.
Make sure pointer handling code handle these modified keys gracefully
and doesn't trigger a key event and a vibration for the removed key.
On some devices, bogus touch events can be sent while holding a key.
With modulated keys, it can happens on top of other keys.
Ignore every new pointers when a modulated key is pressed.
Handling this event is part of the API but was never done. This caused
unstoppable key-repeat.
This event isn't common, the only way I found on Android 10 is to switch
to the emoji keyboard while holding a key. Some apps might cause this
event more often.
Change the formula: don't use an external constant, add a state.
It's now the ratio between where the finger is at the first repeat and
where it is now.
Keep the repeat going when swiping into an other key. Currently only for
arrows: It's now possible to go from an arrow to an other without
waiting again for the key repeat timeout.
The backspace and delete keys don't work well with this.
