summaryrefslogtreecommitdiffstats
path: root/quantum/process_keycode/process_caps_word.c
Commit message (Collapse)AuthorAgeFilesLines
* [Core] Caps Word "Invert on shift" option: pressing Shift inverts the ↵Pascal Getreuer2023-04-041-0/+66
| | | | | | shift state. (#20092) Co-authored-by: Nick Brassel <nick@tzarc.org>
* Fix functions when `NO_ACTION_TAPPING` is defined (#11528)Drashna Jaelre2023-02-191-1/+5
|
* Normalise Swap Hands keycodes (#19720)Ryan2023-01-301-1/+1
|
* Fix keycode parameter extraction to match the new DD keycodes (#18977)Sergey Vlasov2022-11-061-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Add macros to extract parameters from keycode values Implement both encoding and decoding for keycodes like TO(layer) or LM(layer, mod) in one place, so that the decoding won't get out of sync with the encoding. While at it, fix some macros for creating keycode values that did not apply the appropriate masks to parameters (and therefore could allow the result to be out of range if a wrong parameter was passed). * keymap_common: Use extraction macros for keycodes * pointing_device_auto_mouse: Use extraction macros for keycodes Fixes #18970. * process_autocorrect: Use extraction macros for keycodes * process_caps_word: Use extraction macros for keycodes (Also fix a minor bug - SH_TG was not handled properly) * process_leader: Use extraction macros for keycodes (Technically the code is not 100% correct, because it always assumes that the LT() or MT() action was a tap, but it's a separate issue that already existed before the keycode changes.) * process_unicode: Use extraction macros for keycodes * process_unicodemap: Use extraction macros for keycodes
* Deprecate `CAPS_WORD`/`CAPSWRD` for `CW_TOGG` (#18834)Ryan2022-10-241-1/+1
|
* Fix Caps Word to treat mod-taps more consistently. (#17463)Pascal Getreuer2022-08-141-6/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Fix Caps Word to treat mod-taps more consistently. Previously, holding any mod-tap key while Caps Word is active stops Caps Word, and this happens regardless of `caps_word_press_user()`. Yet for regular mod keys, AltGr (KC_RALT) is ignored, Shift keys are passed to `caps_word_press_user()` to determine whether to continue, and similarly, a key `RSFT(KC_RALT)` representing Right Shift + Alt is passed to `caps_word_press_user()` to determine whether to continue. This commit makes held mod-tap keys consistent with regular mod keys: * Holding a `RALT_T` mod-tap is ignored. * When holding a shift mod-tap key, `KC_LSFT` or `KC_RSFT` is passed to `caps_word_press_user()` to determine whether to continue. * When holding a Right Shift + Alt (`RSA_T`) mod-tap, `RSFT(KC_RALT)` is passed to `caps_word_press_user()`. Particularly, with this fix a user may choose to continue Caps Word when a shift mod-tap key is held by adding `KC_LSFT` and `KC_RSFT` cases in `caps_word_press_user()`. For instance as ``` bool caps_word_press_user(uint16_t keycode) { switch (keycode) { // Keycodes that continue Caps Word, with shift applied. case KC_A ... KC_Z: case KC_MINS: add_weak_mods(MOD_BIT(KC_LSFT)); // Apply shift to the next key. return true; // Keycodes that continue Caps Word, without shifting. case KC_1 ... KC_0: case KC_BSPC: case KC_DEL: case KC_UNDS: case KC_LSFT: // <<< Added here. case KC_RSFT: return true; default: return false; // Deactivate Caps Word. } } ``` * Fix Caps Word to treat mod-taps more consistently. Previously, holding any mod-tap key while Caps Word is active stops Caps Word, and this happens regardless of `caps_word_press_user()`. Yet for regular mod keys, AltGr (KC_RALT) is ignored, Shift keys are passed to `caps_word_press_user()` to determine whether to continue, and similarly, a key `RSFT(KC_RALT)` representing Right Shift + Alt is passed to `caps_word_press_user()` to determine whether to continue. This commit makes held mod-tap keys consistent with regular mod keys: * Holding a `RALT_T` mod-tap is ignored. * When holding a shift mod-tap key, `KC_LSFT` or `KC_RSFT` is passed to `caps_word_press_user()` to determine whether to continue. * When holding a Right Shift + Alt (`RSA_T`) mod-tap, `RSFT(KC_RALT)` is passed to `caps_word_press_user()`. Particularly, with this fix a user may choose to continue Caps Word when a shift mod-tap key is held by adding `KC_LSFT` and `KC_RSFT` cases in `caps_word_press_user()`. For instance as ``` bool caps_word_press_user(uint16_t keycode) { switch (keycode) { // Keycodes that continue Caps Word, with shift applied. case KC_A ... KC_Z: case KC_MINS: add_weak_mods(MOD_BIT(KC_LSFT)); // Apply shift to the next key. return true; // Keycodes that continue Caps Word, without shifting. case KC_1 ... KC_0: case KC_BSPC: case KC_DEL: case KC_UNDS: case KC_LSFT: // <<< Added here. case KC_RSFT: return true; default: return false; // Deactivate Caps Word. } } ``` * Update quantum/process_keycode/process_caps_word.c Co-authored-by: Joel Challis <git@zvecr.com>
* Fix Caps Word capitalization when used with Combos + Auto Shift. (#17549)Pascal Getreuer2022-08-131-0/+4
|
* Continue Caps Word when AltGr (right Alt) is held. (#17156)Pascal Getreuer2022-05-201-1/+4
| | | | | | | | | | | This is a minor bug fix for Caps Word. Currently, Caps Word turns off whenever a non-shift mod becomes active. This is done to avoid interfering with hotkeys. This commit makes an exception to continue Caps Word when AltGr (right Alt) is held. Outside the US, the AltGr key is used to type additional symbols (https://en.wikipedia.org/wiki/AltGr_key). Depending on the language, these may include symbols used within words like accented letters where it would be desirable to continue Caps Word.
* [Core] Add Caps Word feature to core (#16588)Pascal Getreuer2022-05-141-0/+160
Co-authored-by: precondition <57645186+precondition@users.noreply.github.com> Co-authored-by: Drashna Jaelre <drashna@live.com>