caps_word_is_numeric may need to honor ev->implicit_modifiers
#2723
Comments
|
+1 |
matthewtodd
added a commit
to matthewtodd/zmk
that referenced
this issue
Dec 22, 2024
Fixes zmkfirmware#2723. I discovered this by trying to use caps_word for comment markers like `FIXME(mt):` and finding that the opening left parenthesis didn't deactivate caps_word.
matthewtodd
added a commit
to matthewtodd/zmk
that referenced
this issue
Dec 22, 2024
Fixes zmkfirmware#2723. The caps_word behavior now strictly honors `[A-Za-z0-9_]` as the default continuation characters. Previously `!@#$%^&*()` were mistakenly also honored. I discovered this by trying to use caps_word for comment markers like `FIXME(mt):` and finding that the opening left parenthesis didn't deactivate caps_word.
matthewtodd
added a commit
to matthewtodd/zmk
that referenced
this issue
Dec 22, 2024
Fixes zmkfirmware#2723. The caps_word behavior now strictly honors `[A-Za-z0-9_]` as the default continuation characters. (Previously `!@#$%^&*()` were mistakenly also honored.) I discovered this by trying to use caps_word for comment markers like `FIXME(mt):` and finding that the opening left parenthesis didn't deactivate caps_word.
5 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I write comments like
FIXME(mt):and find that&caps_worddoesn't deactivate after the opening parenthesis, though I would like it to!I suspect this is because
caps_word_is_numericonly looks at the 8-bit keycode, and that it should also take modifiers into account, perhaps somewhat ascaps_word_is_caps_includelistdoes.(Indeed, on further experimentation, I find that
&caps_wordstays active through all of!@#$%^&*(), which seems to corroborate the suspicion.)Does all that seem right?
(Also, thank you for ZMK, I'm very grateful for your work!)
The text was updated successfully, but these errors were encountered: