Add the 'catchall' keyword that matches all keys #4930
Merged
Conversation
This file contains 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
This keyword can be used to define arbitrary keybinds. The only special behavior that it exhibits is that it matches every key, including modifier keys. Any flags still apply normally. This commit also fixes an issue that keys bound via the code:KEYCODE format were not unbound correctly.
|
the warning in the wiki is relatable - how about ignore catchall outside submaps? |
|
That's definitely an option. In fact, that is what I intended to propose under the 'Footgun' section above. Since it is known at parse-time whether the bind would be in a submap, maybe it could even be a validation error instead of just ignoring it? Update: I went ahead and implemented that. |
A catchall keybind outside a submap would prevent essentially all key events from going through to applications and would be difficult to remove again.
|
Thank you for reviewing and merging that so quickly! |
|
⛰️ 🚗 |
lisuke
pushed a commit
to lisuke/Hyprland
that referenced
this pull request
Apr 15, 2024
* Add the 'catchall' keyword that matches all keys This keyword can be used to define arbitrary keybinds. The only special behavior that it exhibits is that it matches every key, including modifier keys. Any flags still apply normally. This commit also fixes an issue that keys bound via the code:KEYCODE format were not unbound correctly. * Disallow catchall keybinds outside of submaps A catchall keybind outside a submap would prevent essentially all key events from going through to applications and would be difficult to remove again.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This keyword can be used to define arbitrary keybinds. The only special behavior that it exhibits is that it matches every key, including modifier keys. Any flags still apply normally.
Motivation
I use submaps to create modal keymaps similar to those implemented by many Vim configs, e.g. LazyVim. Then I might hit
<leader> l mto launch my system monitor. While in a submap I would like to ignore any keys that are not mapped and open a help window that reminds me of my forgotten binds. Adding a catch-all bind seemed to be the most straight-forward way to achieve that.This or a similar feature is also requsted by #3638, #3405 and #1972.
Fixed Issues
This commit also fixes an issue that keys bound via the
code:KEYCODEformat were not unbound correctly. This problem stemmed from a duplication of the code that translates the key specification in a bind rule (i.e. its second argument) to keysym/keycode. Since I had to touch that code anyway and to avoid similar problems in the future, I extracted that code into a function.Open questions
Syntax
The keyword could theoretically collide with a keysym. However, I believe it to be unlikely that a keysym with such a name will ever exist, so this is a limited risk. To be extra sure or future proof for new keywords, it is conceivable to instead use syntax such as
special:catchall. The currentcode:syntax for binding by keycode would be precedent for that.I am also not 100% sold on the formatting by hyprctl or more specifically the casing of the name. I tried to remain consistent with the existing fields, specifically
non_consumingbeing snake_case in the JSON output and everything being lowercase in the other output.Footgun
Using this keyword outside a submap will prevent essentially all keys from being forwarded to applications (unless defined as non-consuming). This might make it difficult to revert the setting. The setting could be made to only work in a submap to mitigate that.
Since switching to a TTY should still work, I don't view this as a huge problem. I would rather remain consistent with existing behavior and introduce fewer special cases.
Documentation
I have prepared an accompanying PR at hyprwm/hyprland-wiki#499.