Using Achordion with custom keys that send a different key tap when held

[jweickm]

I've been giving Achordion a shot and so far I am really liking it. In feel it's quite similar to the custom solution that I had made previously, but it was much easier to deploy and customize. I may have missed something, but one issue I encountered was with the use of custom key codes that send a different tap event when held. On my Planck I mainly use these to send : when holding . or to send a number when holding the respective top row key longer than the tapping term. These key codes follow the following pattern to override the hold event (in process_record_user):

case Q_KEY:
    if (record->tap.count && record->event.pressed) {
        // normal processing when tapped
        return true;
    } else if (record->event.pressed) {
        // send a different key code when held
        tap_code(KC_1);
        return false;
    }
    return true;

When I let Achordion handle these key codes the held event is not sent. I was under the impression, that Achordion would process the key's hold event "normally" after a certain timeout. So currently, the only way for me to get these keys to work is to define them as exceptions in achordion_timeout and set their timeout to 0. Is there any way to get the desired behaviour of these keys (sending the hold event, i.e. an alternative key tap after the tapping term expired) while also retaining the benefits of Achordion with these keys?

I hope that this issue is not just relevant for my specific use case and that other users of Achordion can also benefit from an answer to this issue. At any rate, thanks for sharing this awesome (and very well documented) userspace library!

Best, jweickm

[getreuer]

Thanks for the report and kind words! You are right, while Achordion passes along tap events, it isn't passing on hold events as it should.

I want to make sure I understand the use case you describe. Is this essentially a tap dance-like effect to do two different things on tap vs. long press? I read something similar in filterpaper's repo: tap-hold macros. For this "tap-hold dance" use, I would think the tap-hold decision would preferably be based only on whether the key is held longer than the tapping term, without consideration about other key events while the key is down, and bypassing Achordion seems reasonable to me. But I don't have much experience with this use of a tap-hold key, so this may be naive. For these keys, is there something about the tap-hold decision that you would want to customize with Achordion?

In any case, it's an oversight that Achordion doesn't pass along the hold events. I'll look into fixing that.

[jweickm]

Hi Pascal,

thank you for your quick reply. I am not actually using the QMK tap dance feature but my custom keycode is very similar in function. These custom keycodes override the hold event of LT() key macros to send a tap event of a different key. For example, when I hold the Q key it will tap KC_1 once after a short delay, allowing me to use the top row of my Planck as a number row without having to switch layers.

I just looked through the link you shared. It is indeed very similar.

For this "tap-hold dance" use, I would think the tap-hold decision would preferably be based only on whether the key is held longer than the tapping term, without consideration about other key events while the key is down, and bypassing Achordion seems reasonable to me.

Yes, that is the desired behaviour but bypassing Achordion entirely doesn't provide me with the benefits of preventing the accidental triggering of hold-events when rolling. What I like about your Achordion is, that I can type a little more lazily without triggering accidental hold events. When using home-row mods, LALT_T(KC_R) + LSFT_T(KC_S) becomes rs when typed in quick succession with the finger lingering on the first key. When doing the same with one of the custom keycodes where Achordion is bypassed, the result of lazily typing is 9u instead of yu for example (so the hold event is triggered for the first key). It would be great if these keys could be handled in the same way as mod-taps (as they are essentially "layer taps").

Thanks for looking into that! Overall, still a truly awesome userspace library. I hope that it will be included in the main QMK distribution at some point!

Best,

jweickm

[getreuer]

Hi Jakob! I just pushed commit https://github.com/getreuer/qmk-keymap/commit/87eb4e57623fee5eefda37951c31327a7234f7eb which should fix this issue, but please reopen if you notice anything further. Thanks again for reporting this!

[jweickm]

Hi Pascal! Thanks for being so amazing to change the whole way that Achordion handles held events to allow for a broader range of custom keycodes to be used with it! Will try it out asap.

[getreuer]

You're welcome =) Thanks for helping make Achordion better!

[jweickm]

Just wanted to check in again to report that it has been working just as expected and the feeling of Achordion is really great! Especially on Colemak with a lot of rolls, I feel that I can type much faster and less carefully now! Thanks again for sharing and updating your userspace libraries! =)

[getreuer]

That's awesome to hear! Colemak with all its rolling is a great stress test. Thanks for the feedback!