Allow customization of which keys caps_word modifies #1742

joelspadin · 2023-04-08T16:40:01Z

Added new options to &caps_word to bring it closer to feature parity with QMK:

Added shift-list to include extra keys to have modifiers applied, for example to change MINUS to UNDERSCORE. Anything specified in this list is implicitly part of continue-list.
Added no-default-keys, which removes the implicit alphanumeric keys from continue-list and shift-list when set. This allows fully customizing the keys, for example for non-US layouts.

Kikangh · 2023-04-08T19:25:20Z

WoW ! Thanks for working on the no-default-keys part, as a foreign (exotic) layout user, this should make it a wee bit easier for me to setup caps_word for my use case 🙏

theol0403 · 2023-04-08T19:36:23Z

How does this compare to the features added to #1451?

joelspadin · 2023-04-08T19:56:35Z

How does this compare to the features added to #1451?

From my understanding of that PR, they are almost completely different. That PR does the following:

Adds a way to activate a layer instead of/in addition to activating modifiers.
Adds a way to select whether alphas, numbers, and/or modifiers continue/break a word.
Any custom zmk,behavior-caps-word behaviors will change as follows unless they are updated:
- No modifiers are applied unless mods is set.
- Word break occurs on any key not in continue-list (previously alphanumeric and modifier keys would always continue a word)

To restore the original behavior of a custom caps word behavior, add:

mods = <MOD_LSFT>;
ignore-alphas;
ignore-numbers;
ignore-modifiers;

This PR does:

Adds a way to select the specific keys that continue/break a word (except modifiers, which still always continue, but that could be changed if necessary).
Adds a way to select the specific keys that have modifiers applied to them.
Adds a timeout where caps word will deactivate if no key is pressed for some time.
&caps_word now defaults to shifting '-' to underscore _ and having a 5 second idle timeout.
Any custom zmk,behavior-caps-word behaviors will change as follows unless they are updated:
- A 5 second idle timeout is added.

To restore the original behavior of a custom caps word behavior, add:

idle-timeout-ms = <0>;

theol0403 · 2023-04-08T20:08:12Z

Thanks for the detailed explanation! Looking forward to seeing both of these merged.

caksoylar · 2023-04-09T02:55:56Z

Would you consider adding explicit modifier changes (discussed around here) to this PR, or a separate one?

joelspadin · 2023-04-09T03:36:22Z

I was thinking to do that in a separate change to keep this easier to review.

joelspadin · 2023-04-10T04:18:39Z

Fixes #1706

theol0403 · 2023-04-11T04:31:58Z

Defaults to MINUS so hyphens get turned into underscores.

I would say wanting to type in UPPER-DASH-CASE is common enough that having it shift to underscore automatically might be too opinionated for a default. In my personal config, I have hyphen and underscore on separate keys in a symbol layer (pretty common), so would need to explicitly disable this default because I would then have two underscores on my symbol layer during caps word.

Perhaps I am misunderstanding, but wouldn't having hyphens in the default shift-list also require hyphens to be in the default continue-list (which is only A-Z)?

joelspadin · 2023-04-11T05:26:07Z

I would say wanting to type in UPPER-DASH-CASE is common enough that having it shift to underscore automatically might be too opinionated for a default. In my personal config, I have hyphen and underscore on separate keys in a symbol layer (pretty common), so would need to explicitly disable this default because I would then have two underscores on my symbol layer during caps word.

I chose this to align with QMK's default behavior. I could change it back if enough people agree that it shouldn't be the default, but it's also easy enough to disable with

&caps_word {
  shift-list = <>;
};

Perhaps I am misunderstanding, but wouldn't having hyphens in the default shift-list also require hyphens to be in the default continue-list (which is only A-Z)?

MINUS was added to the default continue list here: https://github.com/zmkfirmware/zmk/pull/1742/files#diff-315ee987c216e30d02008e39328bdb6be66f3348ad7a799468e2467de2f2f8d2R15 The default list is now A-Z, 0-9, hyphen, underscore, backspace, and delete.

joelspadin · 2023-04-11T05:26:57Z

Reminder to myself: this is missing a test for no-default-keys.

infused-kim · 2023-04-11T17:10:41Z

I chose this to align with QMK's default behavior. I could change it back if enough people agree that it shouldn't be the default

I also agree this shouldn’t be the default for the exact same reasons @theol0403 outlines.

I think the intention of activating caps lock or caps word is to type words in caps. Symbols can be shifted with shift when necessary.

And just because qmk chose a poor default setting, it doesn’t mean that zmk should copy it.

joelspadin · 2023-04-11T20:41:17Z

Added more tests, updated the documentation, and changed so that anything in shift-list will also be treated as a continue key, so you don't need to add keys to both lists for them to work.

joelspadin · 2023-04-11T21:01:18Z

Are you advocating for changing the default so that - continues a word but does not get shifted to _? Or, do you just mean that - should end a word, so to type out UPPER-DASH-CASE you'd press caps word again at the start of each word?

If you do think the default should change, in what situations would that be used? I can't think of any, but I'm also a primarily C/C++ programmer, so I'm much more familiar with use cases for SCREAMING_SNAKE_CASE than for SCREAMING-KEBAB-CASE.

infused-kim · 2023-04-11T21:33:52Z

Are you advocating for changing the default so that - continues a word but does not get shifted to _? Or, do you just mean that - should end a word, so to type out UPPER-DASH-CASE you'd press caps word again at the start of each word?

If you do think the default should change, in what situations would that be used? I can't think of any, but I'm also a primarily C/C++ programmer, so I'm much more familiar with use cases for SCREAMING_SNAKE_CASE than for SCREAMING-KEBAB-CASE.

I see where you are coming from with these defaults. I think I am approaching it from a slightly different point of view.

1. Shifting "-" or not by default

I think caps word should behave as closely to "normal" caps lock as possible. Normal caps lock (at least on macOS) doesn't seem to shift any symbols or numbers. It seems to only affect letters.

And I think caps word should behave exactly the same way in the default config. That's the behavior a user would expect and so that's what they should get.

On top of that, only shifting one symbol, but not any of the other symbols by default is extra confusing and unexpected.

So I think it would be best to avoid that.

I do think that your use-case makes perfect sense and many programmers would probably prefer that behavior. But I think it should be an option and not a default.

And even though a portion of users would prefer that behavior, it's not like it is impossible to type a "_" without the default. Users can just type shift+- and that's what most users would expect to have to do anyways (even with normal caps lock).

2. Should "-" deactivate caps word or not by default

This one is a bit more difficult to answer, because we don't have any pre-existing behavior that users might be used to.

I think I would lean towards keeping capsword enabled on both "-" and "_". Simply, because I can't think of many instances where a user wouldn't type another deactivating character like , ., or ; after the underscore or dash.

infused-kim · 2023-04-11T21:49:11Z

I just thought of two more reason against shifting "-“ by default :). I hope you don’t mind….

Doing so also makes it impossible to actually type “-“ during caps word should the user desire to do so.

For many users that’s fine, but it should be a conscious decision and not unexpected behavior.

The beauty of caps word is that it makes your life easier and then seamlessly gets out of the way.

But users won’t use it just to type programming definitions like “FOO-BAR” or “FOO_BAR”.

Sometimes people may type a sentence like “[…] and that’s why this is BAD-- I won’t allow this.”

The expectation here is that “I can just type and don’t need to worry about turning off caps word or weird exceptions”.

theol0403 · 2023-04-13T01:24:52Z

I agree with @infused-kim. Personally, the biggest issue for me with having hyphen shifted by default is the inability to type "-" during caps word, which doesn't feel like a natural default. This is extra relevant to me because I already have a dedicated "_" key on a layer and don't use shift+"-".

Another very minor point is that looking through the source code and docs, the need to make several references to "MINUS" to explain its behaviour reflects its unintuitive nature.

While it is very easy to remove the default behaviour, it is equally easy to add behaviour, and I think more users would expect the default to be unopinionated. I think it would make more sense to have "For example, to add MINUS to the shift list so it is automatically changed to UNDERSCORE, add:" in the docs (as a nice way to guide the reader towards this possibly desired feature, and show how it is used instead of how to disable).

Finally, I have fewer opinions on whether MINUS should be in continue-list by default, but I vote to keep it.

joelspadin · 2023-04-18T01:45:32Z

The latest version removes MINUS so the default behavior is unchanged.

joelspadin · 2023-05-14T17:12:30Z

Rebased and fixed whitespace issues for pre-commit.

petejohanson

Couple questions on the implementation. Thanks!

petejohanson · 2023-05-19T00:04:06Z

app/include/zmk/keys.h

@@ -20,6 +22,21 @@ struct zmk_key_event {
    bool pressed;
 };

+struct zmk_key_decoded {


Not sure I love the decoded terminology... Complete key? Key details? Full key?

Since this is all the data from a DT parameter, how about zmk_key_param?

app/src/behaviors/behavior_caps_word.c

SebastianBehrens · 2023-08-16T09:44:51Z

Hi @petejohanson, are you hesitant to merge this; or can one expect this to clear soon?

ctranstrum · 2023-10-21T04:53:32Z

+1 on merging this one

Changed behavior_caps_word.c to be conditionally compiled instead of wrapping the entire contents of the file in an #if. Renamed macros that still referred to "break" instead of "continuation". Changed the type of the continuations count field to allow for more than 255 continuation keys. Reordered a struct to allow for better packing. Switched to statically initializing the devs[] array instead of using an index field in each device's config struct and the init function. Refactored caps_word_keycode_state_changed_listener() and caps_word_enhance_usage() to allow for more easily changing the conditions for what breaks a word and whether mods should be applied in future commits.

Unified devicetree key code parameter decoding between key press and caps word behaviors. Reordered zmk_keycode_state_changed fields for better packing.

Added a shift-list property to caps word to allow adding more keys to be shifted aside from alpha keys. Added a &prog_word behavior, which is the same as &caps_word, except it adds MINUS to shift-list (this matches QMK's caps word behavior). Added a no-default-keys property to caps_word, which removes the implicit alphanumeric keys from continue-list and shift-list so you can fully customize the lists. Also adjusted the default continue keys to include numpad numbers, since those are numbers too.

joelspadin · 2024-03-20T02:26:31Z

Rebased, cleaned up and simplified the code some more, and dropped the idle timeout feature for now. Macros can cause keys to be pressed a different number of times than they are released, so counting the number of presses and releases to determine when no keys are pressed isn't reliable. Doing that correctly will require some changes to core code, so I'll handle that separately.

joelspadin force-pushed the caps-word branch from bca0934 to 8f3142a Compare April 8, 2023 19:39

joelspadin force-pushed the caps-word branch 2 times, most recently from a1b5b03 to 18ad62e Compare April 8, 2023 21:42

joelspadin force-pushed the caps-word branch 2 times, most recently from a33d657 to 3cf9e06 Compare April 11, 2023 20:39

joelspadin mentioned this pull request Apr 20, 2023

Feature Request: relaese-after-ms for caps_word #1765

Open

joelspadin force-pushed the caps-word branch from 45b7171 to 58c74ac Compare May 14, 2023 17:12

petejohanson requested changes May 19, 2023

View reviewed changes

caksoylar added enhancement New feature or request behaviors labels Jun 10, 2023

joelspadin force-pushed the caps-word branch from 58c74ac to 37c2d3f Compare June 11, 2023 03:19

joelspadin requested a review from a team as a code owner June 11, 2023 03:19

theol0403 mentioned this pull request Jun 22, 2023

feat: &caps_word for single letter or BSPC-resistant &sk #1712

Open

joelspadin mentioned this pull request Dec 2, 2023

Capslock behavior #2043

Open

joelspadin added 3 commits March 19, 2024 20:42

refactor: Deduplicate key code decoding

0476340

Unified devicetree key code parameter decoding between key press and caps word behaviors. Reordered zmk_keycode_state_changed fields for better packing.

joelspadin force-pushed the caps-word branch from 37c2d3f to 69c7d02 Compare March 20, 2024 02:23

joelspadin changed the title ~~Bring caps word to feature parity with QMK~~ Allow customization of which keys caps_word modifies Mar 20, 2024

urob mentioned this pull request May 7, 2024

feat(behaviors): Smart-layers (e.g., num-word) and caps-word enhancements #1451

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow customization of which keys caps_word modifies #1742

Allow customization of which keys caps_word modifies #1742

joelspadin commented Apr 8, 2023 •

edited

Loading

Kikangh commented Apr 8, 2023

theol0403 commented Apr 8, 2023

joelspadin commented Apr 8, 2023

theol0403 commented Apr 8, 2023

caksoylar commented Apr 9, 2023

joelspadin commented Apr 9, 2023

joelspadin commented Apr 10, 2023

theol0403 commented Apr 11, 2023 •

edited

Loading

joelspadin commented Apr 11, 2023

joelspadin commented Apr 11, 2023

infused-kim commented Apr 11, 2023

joelspadin commented Apr 11, 2023

joelspadin commented Apr 11, 2023

infused-kim commented Apr 11, 2023

infused-kim commented Apr 11, 2023 •

edited

Loading

theol0403 commented Apr 13, 2023 •

edited

Loading

joelspadin commented Apr 18, 2023

joelspadin commented May 14, 2023

petejohanson left a comment

petejohanson May 19, 2023

joelspadin Jun 11, 2023

SebastianBehrens commented Aug 16, 2023 •

edited

Loading

ctranstrum commented Oct 21, 2023

joelspadin commented Mar 20, 2024

Allow customization of which keys caps_word modifies #1742

Are you sure you want to change the base?

Allow customization of which keys caps_word modifies #1742

Conversation

joelspadin commented Apr 8, 2023 • edited Loading

Kikangh commented Apr 8, 2023

theol0403 commented Apr 8, 2023

joelspadin commented Apr 8, 2023

theol0403 commented Apr 8, 2023

caksoylar commented Apr 9, 2023

joelspadin commented Apr 9, 2023

joelspadin commented Apr 10, 2023

theol0403 commented Apr 11, 2023 • edited Loading

joelspadin commented Apr 11, 2023

joelspadin commented Apr 11, 2023

infused-kim commented Apr 11, 2023

joelspadin commented Apr 11, 2023

joelspadin commented Apr 11, 2023

infused-kim commented Apr 11, 2023

1. Shifting "-" or not by default

2. Should "-" deactivate caps word or not by default

infused-kim commented Apr 11, 2023 • edited Loading

theol0403 commented Apr 13, 2023 • edited Loading

joelspadin commented Apr 18, 2023

joelspadin commented May 14, 2023

petejohanson left a comment

Choose a reason for hiding this comment

petejohanson May 19, 2023

Choose a reason for hiding this comment

joelspadin Jun 11, 2023

Choose a reason for hiding this comment

SebastianBehrens commented Aug 16, 2023 • edited Loading

ctranstrum commented Oct 21, 2023

joelspadin commented Mar 20, 2024

joelspadin commented Apr 8, 2023 •

edited

Loading

theol0403 commented Apr 11, 2023 •

edited

Loading

infused-kim commented Apr 11, 2023 •

edited

Loading

theol0403 commented Apr 13, 2023 •

edited

Loading

SebastianBehrens commented Aug 16, 2023 •

edited

Loading