Fix Caps Word and Unicode Map

[kosorin]

Description

Caps Word doesn't work with Unicode Map pairs XP(a, A).

I changed order of calling process_caps_word in process_record_quantum. Moved it before process_unicode_common.

In unicode_input_start I just clear weak_mods. I don't know if it breaks anything else. I'm still a little bit confused with weak mods and how they work. Maybe save and restore weak_mods after sending unicode keys, just like mods? Or is it unnecessary?

User function caps_word_press_user can look like this:

bool caps_word_press_user(uint16_t keycode) {
    switch (keycode) {
        case KC_A ... KC_Z:
        case QK_UNICODEMAP_PAIR ... QK_UNICODEMAP_PAIR_MAX: // use whole range or filter only required pairs
            add_weak_mods(MOD_BIT(KC_LSFT));
            return true;

        default:
            return false;
    }
}

Btw I just noticed that there is also another bug fix (#17240) that changes the order of calling process_caps_word.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[tzarc]

Similar class of issue as per #17240.
@drashna @getreuer probably need some input here, too.

[getreuer]

This looks good to me. Thanks for submitting the fix!

[KarlK90]

@kosorin your fix is part of #17284 which got merged to master. Thanks for your contribution, closing this.