[BUG] Capsword not working on HoldTap keys

[halfdane]

Describe the bug When tapping a HoldTap character with Capsword active, the character isn't sent shifted.

To Reproduce Have a HoldTap key with a character (p.e. KC.R) and tap it while Capsword is active.

Steps to reproduce the behavior:

Here's a minimal example of the problem

R_ALT=KC.HT(KC.R, KC.LALT, prefer_hold=False, tap_interrupted=True, tap_time=150)

keyboard.keymap = [ [
   KC.TD(KC.CW, KC.CAPS, tap_time=200), KC.F, R_ALT,  
] ]

Tapping all keys from left to right exactly once results in: Fr (Please note that the second character isn't capitalized, although CapsWord is active.)

(Tapping the first key twice will result in the expected output: FR)

Expected behavior All characters should be shifted while Capsword is active, even if they're "hidden" in HoldTap

Additional context I suspect that the capsword code is dismissing the HoldTap key at https://github.com/KMKfw/kmk_firmware/blob/main/kmk/modules/capsword.py#L37, because it's an internal key without a code. The result of HoldTap is then processed with resume_process_key without further handling of other modules like Capsword, and consequently sent unshifted (https://github.com/KMKfw/kmk_firmware/blob/main/kmk/modules/holdtap.py#L251)

If that's indeed the reason, capsword might be broken for all keys that don't have a code - which would be all internal keys, I guess.

[xs5871]

Would you mind testing #1009?

[halfdane]

I won't be able to do that before the week after the upcoming one, but then I'll be happy to check it out 😊

[halfdane]

Sorry it took me so long, but now I got around to test your change. Sorry to say that I didn't see any change in the behaviour whatsoever, so the minimal example from the initial report still triggers the bug in the same way.