fix MENUCOLOR non-attribute overriding #1064
Conversation
One may make their wearing and wielding items underlined. `MENUCOLOR="(being worn|wielded)"=gray&underline` But the latter matching rules only setting a color will change the line's attribute none. It forces players to manually copy their rules and add underlined versions. `MENUCOLOR="(robe)"=bright magenta` `MENUCOLOR="(robe).*worn"=bright magenta&underline` So if the matching rule's attr is ATR_NONE, we keep searching back previous rules to find the first matching rule which provides an attribute. This may slightly influence the performance due to more regex_match. But makes the config more concise if one has many MENUCOLORs.
|
I think the menu-color data will need to have flags that distinguish between no color specified and explicitly specified NO_COLOR;similarly for attributes. A second rule should only be found and used if the first one leaves either of the two fields unspecified and the second rule fills in the gap. (Probably when the second rule only fills in the gap rather than specify both color and attribute.) Also, this now falls off the end of the loop and returns False if a pattern specifying color&no-attr matches but no other pattern which also matches is found when looking for an attribute one. (I haven't looked to see whether the called really cares about the return value.) |
|
Thanks for your reply! Yes I agree the MENUCOLOR rules may need more design, I find it cannot specify only attributes. I heard that there's a MENUCOLOR patch but I don't know what it does, for me cuz I wrote maybe hundreds of menucolors in my .nethackrc, the main problem is the rules don't fall back to check attributes, so I need to add one more underline version to every color rule. Somewhat painful lol. |
move the custom color data into its own field in the glyphmap and disassociate it from the unicode/utf8 stuff. move the glyphcache stuff during options processing and parsing into new file glyphs.c and out of utf8map.c, and make it general, and not part of ENHANCED_SYMBOLS. Do the groundwork for allowing glyph color customizations to work when any symset is loaded and not restrict it only to the enhanced1 H_UTF8 symsets. The customizations in effect are still affiliated with a particular symset. Also closes #1224, but the PR itself references a data structure made obsolete by this commit. The curses comment from the PR was added into the code. The PR also made several suggestions, but only the first one has been included in this commit (and no longer based on the handler), that being: "allow defining colors if other symbol handling modes are used (possibly limited to the standard 16 colors)." FredrIQ also wrote the following suggestions in PR#1224: Something I was also contemplating, unrelated to implementation of this support in curses, would be the ability for the following: allow defining colors if other symbol handling modes are used (possibly limited to the standard 16 colors) allow defining attributes (for example: glyph:G_pet_female_kitten:U+0066/red/underline) allow specifying glyphs as wildcards for defining global color/attribute changes Something I also want to see are keywords for "don't change the current defined data". If this were to be added, you could for example do this: OPTIONS=glyph:G_*_fox:U+0064/blue OPTIONS=glyph:G_statue_*:basechar/gray/underline for "make all foxes use a blue color, make all statues gray with underline" without needing to specify the relevant character for every statue. This ("basechar", "basefg", etc) should perhaps also be added for MENUCOLORS and statushilites, so that you can, for example, underline all items being worn without needing to specify a bunch of near-duplicate rules for combining BUC colors + underline worn items as per #1064
One may make their wearing and wielding items underlined.
MENUCOLOR="(being worn|wielded)"=gray&underlineBut the latter matching rules only setting a color will change
the line's attribute none. It forces players to manually copy
their rules and add underlined versions.
MENUCOLOR="(robe)"=bright magentaMENUCOLOR="(robe).*worn"=bright magenta&underlineSo if the matching rule's attr is ATR_NONE, we keep searching
back previous rules to find the first matching rule which provides
an attribute.
This may slightly influence the performance due to more regex_match.
But makes the config more concise if one has many MENUCOLORs.