You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are currently several bugs in the logic of the combo module (as mentioned on [Zulip](#KMK development > Combo behavior on key release).
For the test examples, I assume the default test layer from the combo unittests: [KC.A, KC.B, KC.C, KC.D, KC.E, KCMO, KC.F, KC.G] and the same general setup.
BUG 1
A small one: when match_coord=True and only a 0 remains for a combo (remaining = [0]), this will result in any(remaining) = False, triggering combos even though the 0-key has not been pressed. For example:
The actual result is [{KC.X}, {}] because the 0 is not taken into consideration.
I've already fixed this one (see here, but hadn't opened a pull request so far because I was expecting a bigger rewrite for other things (see also the [Zulip post](#KMK development > Combo behavior on key release). I can still make a PR, if wished.
BUG 2
When two combos overlap and the first one is not completed, this will prohibit the second combo from triggering. For example:
The actual result are only the raw inputs, with no combos being activated {'A'}, {'A', 'B'}, {'B'}, {}, {'A'}, {'A', 'B'}, {'B'}, {}.
I guess one could argue this is intended behavior and is more of a feature request than a bug report, but this way combos are pretty much unusable when typing at higher speeds.
The text was updated successfully, but these errors were encountered:
There are currently several bugs in the logic of the combo module (as mentioned on [Zulip](#KMK development > Combo behavior on key release).
For the test examples, I assume the default test layer from the combo unittests:
[KC.A, KC.B, KC.C, KC.D, KC.E, KCMO, KC.F, KC.G]
and the same general setup.BUG 1
A small one: when
match_coord=True
and only a 0 remains for a combo (remaining = [0]
), this will result inany(remaining) = False
, triggering combos even though the 0-key has not been pressed. For example:The actual result is
[{KC.X}, {}]
because the 0 is not taken into consideration.I've already fixed this one (see here, but hadn't opened a pull request so far because I was expecting a bigger rewrite for other things (see also the [Zulip post](#KMK development > Combo behavior on key release). I can still make a PR, if wished.
BUG 2
When two combos overlap and the first one is not completed, this will prohibit the second combo from triggering. For example:
The actual result will be
[{KC.A}, {}, {KC.B}, {}, {KC.D}, {}]
BUG 3
Combos don't trigger if typed too fast and another combo was still matching. For example:
The actual result are only the raw inputs, with no combos being activated
{'A'}, {'A', 'B'}, {'B'}, {}, {'A'}, {'A', 'B'}, {'B'}, {}
.I guess one could argue this is intended behavior and is more of a feature request than a bug report, but this way combos are pretty much unusable when typing at higher speeds.
The text was updated successfully, but these errors were encountered: