Ignore-modifiers property for capsword

[urob]

This adds an ignore-modifiers property to caps_word. If set to true (the default), caps word will remain active when any modifiers are pressed. This is the current behavior.

This PR allows the user to overwrite the behavior by deleting the (new) ignore-modifiers property in their keymap:

&caps_word {
    /delete-property/ ignore-modifiers;
};

When the property is deleted, pressing a modifier will deactivate caps word. This is useful, for example, for people who activate caps word with somewhat complex key combos or tap dances and who wish to deactivate it by simply pressing LEFT_SHIFT.

---

Discussion: for now, the new ignore-modifiers property is set to true by default. This is in order to ensure backwards-compatibility. My personal feeling is, however, that setting it to false would be a more sensible default. But I didn't want to do it without discussion.

[caksoylar]

This feature caused me some confusion recently, while typing a CONSTANT_VALUE in an editor and wanting to accept its completion with ctrl+n, which became ctrl+shift+n and opened a new terminal window and made me think I got a hold-tap stuck.

If I remember correctly this change was introduced so you could type e.g. _ (which requires shifting) without deactivating caps word. Would it make sense to only ignore the modifiers specified in mods?

[urob]

This feature caused me some confusion recently, while typing a CONSTANT_VALUE in an editor and wanting to accept its completion with ctrl+n, which became ctrl+shift+n and opened a new terminal window and made me think I got a hold-tap stuck.

If I remember correctly this change was introduced so you could type e.g. _ (which requires shifting) without deactivating caps word. Would it make sense to only ignore the modifiers specified in mods?

Hm, I have &kp UNDER on a combo, so I don't need to use shift to type _.

~~But I see how having more flexibility here might be useful. Perhaps having a continue-mod-list as suggested in https://github.com/zmkfirmware/zmk/issues/1410 might be the better solution after all.~~ Actually, one can already do this now using this PR. See next comment.

[urob]

This feature caused me some confusion recently, while typing a CONSTANT_VALUE in an editor and wanting to accept its completion with ctrl+n, which became ctrl+shift+n and opened a new terminal window and made me think I got a hold-tap stuck. If I remember correctly this change was introduced so you could type e.g. _ (which requires shifting) without deactivating caps word. Would it make sense to only ignore the modifiers specified in mods?

Hm, I have &kp UNDER on a combo, so I don't need to use shift to type _. But I see how having more flexibility here might be useful. Perhaps having a continue-mod-list as suggested in #1410 might be the better solution after all.

Actually, one could just combine continue-list with /delete-property/ ignore-modifiers to achieve the same as a more flexible continue-mod-list. E.g., suppose we want to continue caps-word on shift but cancel upon all other modifiers. Using this PR, we can do this using:

&caps_word {
    /delete-property/ ignore-modifiers;
    continue-list = <UNDERSCORE  BACKSPACE DELETE LSHFT RSHFT>;
};

[urob]

Closing this as it is superseded by https://github.com/zmkfirmware/zmk/pull/1451