fix(config): correctly match keyed special categories by value being set - #89
Merged
Merged
Conversation
When parsing multiple special category blocks with different key values,
the second block would incorrectly overwrite the first instead of creating
a separate category entry.
Root cause:
When parsing a block like:
wallpaper {
monitor =
path = /path/image.png
}
wallpaper {
monitor = DP-1
path = /path/image.png
}
1. After closing the first block, `currentSpecialKey` resets to ""
2. When parsing `monitor = DP-1` in the second block, the code looks
for an existing category where key value == currentSpecialKey ("")
3. The first category's key value IS "", so it matches incorrectly
4. The second block overwrites the first, leaving only one category
The fix:
When looking for an existing category to reuse, check what field we're
parsing:
- If parsing the KEY field itself, match by the VALUE being set
- If parsing other fields, match by currentSpecialKey (existing behavior)
This ensures `monitor = DP-1` looks for a category with `monitor == "DP-1"`,
not `monitor == ""`, allowing empty string keys to work correctly alongside
non-empty keys.
This bug affects any hyprlang consumer using keyed special categories where
empty string is a valid key value (e.g., hyprpaper's wallpaper category
with `monitor =` for default/wildcard).
Contributor
Author
|
It may be worth noting I first put together this fix (which is what led me to this) hyprwm/hyprpaper#315 - which is technically redundant but might still be worthwhile if you're happy to support the asterisk. |
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
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.
When parsing multiple special category blocks with different key values, the second block would incorrectly overwrite the first instead of creating a separate category entry.
Root cause:
When parsing a block like:
currentSpecialKeyresets to ""monitor = DP-1in the second block, the code looks for an existing category where key value == currentSpecialKey ("")The fix:
When looking for an existing category to reuse, check what field we're parsing:
This ensures
monitor = DP-1looks for a category withmonitor == "DP-1", notmonitor == "", allowing empty string keys to work correctly alongside non-empty keys.This bug affects any hyprlang consumer using keyed special categories where empty string is a valid key value (e.g., hyprpaper's wallpaper category with
monitor =for default/wildcard). A quick query in copilot claimed these (it's the keyed callers which would be impacted):