You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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?
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 can already do this now using this PR. See next comment.
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:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
EDIT: This PR is now superseded by #1451
This adds an
ignore-modifiersproperty tocaps_word. If set totrue(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-modifiersproperty in their keymap: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-modifiersproperty is set totrueby default. This is in order to ensure backwards-compatibility. My personal feeling is, however, that setting it tofalsewould be a more sensible default. But I didn't want to do it without discussion.