Ensure that the prior key in a tap-hold binding is equal to the tap input key when initiating a tap binding

[asleeponpluto]

For example, let's say we map caps-lock to control on hold and to escape on tap. If we press caps-lock and another key while caps-lock is still pressed down, this should initiate the hold functionality 100% of the time.

As it is now if we hold caps-lock, press a key, and release caps lock in less time than the tap-hold threshold, an escape is executed instead of the correct control+key combination.

This can be easily fixed by tracking the last key pressed and comparing it to the key associated with the tap binding. If the keys are the same and the key has been released in less than the specified tap-hold threshold, then execute the tap binding, otherwise execute the hold binding.

Pseudo-code:

if (last_key_pressed == tap_input_key && elapsed_time < tap_hold_threshold) {
    send tap_output_key
} else {
    send hold_output_key // something like this, although the current implementation doesn't allow this since you bind tap and hold keys separately by my understanding
}

If this isn't super easy to fix due to the separation of tap and hold bindings, I would suggest combining tap and hold bindings into one. This makes sense since I can't think of a use case where someone would only make a tap binding or would only make a hold binding.

Hopefully that makes sense :) Regardless, thanks for all the hard work you've put in to hid-remapper so far!

[led]

This is one that bites me too, so it would be good to find a robust solution.

[asleeponpluto]

Another thought is to only have this functionality affect tap bindings. Then users can just remap caps-lock to control as a normal non-hold binding. Then they can create another tap mapping just for escape. So when they "tap" caps-lock it sends a control tap and then an escape tap, which would suffice. This is how hyperkey and dual-key-remap do this.

[jfedor2]

I'm not sure I agree, when typing it's very common to press the next key before releasing the previous one, so if I were to use one of the home row keys as a modifier when held (common on 36-key layouts like Miryoku), I'd be getting unintended ctrl-something keystrokes in the middle of regular text.