Add retro tapping support #55
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -131,8 +131,15 @@ bool process_achordion(uint16_t keycode, keyrecord_t* record) { | |
| } | ||
|
|
||
| if (keycode == tap_hold_keycode && !record->event.pressed) { | ||
| #ifdef RETRO_TAPPING | ||
| bool is_retro_key = IS_QK_MOD_TAP(keycode) || IS_QK_LAYER_TAP(keycode); | ||
| #elif defined(RETRO_TAPPING_PER_KEY) | ||
| bool is_retro_key = get_retro_tapping(keycode, record); | ||
| #else | ||
| bool is_retro_key = false; | ||
| #endif | ||
| // The active tap-hold key is being released. | ||
| if (achordion_state == STATE_HOLDING || is_retro_key) { | ||
| dprintln("Achordion: Key released. Plumbing hold release."); | ||
| tap_hold_record.event.pressed = false; | ||
| // Plumb hold release event. | ||
|
|
@@ -257,4 +264,10 @@ __attribute__((weak)) uint16_t achordion_streak_timeout(uint16_t tap_hold_keycod | |
| } | ||
| #endif | ||
|
|
||
| #ifdef RETRO_TAPPING_PER_KEY | ||
| __attribute__((weak)) bool get_retro_tapping(uint16_t keycode, keyrecord_t *record) { | ||
|
There was a problem hiding this comment. Is this needed? Core QMK has a weak definition of Duplicate definitions of a function normally cause a linking error. I'm not sure how that goes for weak definitions. Come to think of it, it's interesting that a weak definition exists at all. Arguably, a user who set The function There was a problem hiding this comment. You are right! This is removed in the newer version of this PR, since we no longer need to check the retro tapping key status. |
||
| return false; | ||
| } | ||
| #endif | ||
|
|
||
| #endif // version check | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is clever! It's a simpler change than I first expected.
I think the idea with the change on this line is that:
So by simply plumbing the hold release event, the subsequent retro tap handling in this condition will tap the tapping keycode. Is that accurate?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep this is accurate, and your explanation with the two bullet points is actually the core idea of the newer implementation. This was more specific for retro tapping only, the newer version supports all kinds of features where no other keypress happens between the press and release of the key.