Achordion integration with Caps Word

[rschenk]

I'm copying over this message that @getreuer and I exchanged on reddit.

@rschenk:

...the only gotcha that I ran into was figuring out that I needed to invoke Achordion after caps_word in the process_record_user function link to pertinent lines of my keymap

@getreuer:

It's great that you have Achordion successfully running after Caps Word. Please feel free to continue doing that =)
OTOH, I would like to debug the situation when Achordion runs before Caps Word. That's supposed to be the "correct" order in principle. The way Achordion works is it catches QMK's tap-hold events, blocks them from being handled further, then plumbs modified events back into the handling pipeline. For this to go smoothly, Achordion should run as early as possible, since anything running before it will see both the original event from QMK and the event from Achordion.

When you had Achordion's handler called before Caps Word, could you describe the way it didn't work?
Going out on a limb, I guess Caps Word didn't activate. When using Caps Word, do you activate it by holding both your home row shifts SFT_F + SFT_J and waiting out the tapping term (and not KC_LSFT + KC_RSFT or something else that calls caps_word_set(enable))?

Yes, I am running Caps Word on SFT_F + SFT_J. When I had Caps Word being invoked after achordion in my process_record_user function, most of the time, Caps Word would not invoke. When it did work, I believe the procedure was:

• Hold SFT_F for a long time
• I think until achordion_timeout expired
• Then start holding SFT_J, also for a while
• I think when tapping term expired for SFT_J
• then Caps Word would activate.

I'm pretty vague on the details because it took a while to get Caps Word to invoke, and even then it was very inconsistent.

Placing Caps Word ahead of Achordion solves the problem, but I understand what you're saying about how it's desirable to invoke Achordion as soon as possible. I may just do as you suggested and put Caps Word onto a macro!