Instead of handling resumed key events in a deep stack, buffer them
until the next main loop iteration. New resume events that may be emitted
during handling of old resumes are prepended to that buffer, i.e. take
precedence over events that happen deeper into the buffer/event stack.
Logical replay order is thus preserved.
Faulty logic corrected
Possibly a bug could happen whenever entering ht_press with a non-empty key_state outside of repeat context (but can it really happen?)
Some formatting to make github tests happy
Documentation for repeat behavior.
Make the tests happy again!
same...
* extract tapdance logic into a module
* clean out old tapdance code
* canonicalize key variable names
* split _process_tap_dance into td_pressed and td_released
* implement consistent argument order
* update documentation
* implement Module.process_key for key interception and modification
* fix tapdance realesing instead of pressing
* fix: default parameters in key handler
* cleanup holdtap
* add error handling to modules process_key
* fix: key released too late
Tapped keys didn't release on a "key released" event, but waited for a
timeout. Resulted in, for example, modifiers applying to keys after the
modifier was released.
* fix lint/formatting
* fix tap_time reference in modtap + minimal documentation
* fix lint
