display.h -- bring an unused macro up to date
detect.c -- always call newsym() when searching or secret door
detection finds a trap rather than just when not blind
glyphs.c -- some formatting
pager.c -- lookat() behaves very strangely when single-stepping
in the debugger (gdb); this didn't help
This makes custom S_sw_tc etc. from Enhanced1 symset actually work,
yielding nice smooth outlines for swallowers and explosions. Or so I
think, I have only tested the former because when playing locally,
explosions disappear so fast I cannot see them.
While looking at where else glyph_to_swallow was used, I noticed that
parse_id subtracted S_sw_tl from glyph_to_swallow, even though it
returns 0 to 7. This looks like it would cause out-of-bounds access and
perhaps a segfault when trying to customise glyphs for individual
monster swallow glyphs (or whatever it is parse_id is used for), but
I haven't tried to confirm nor change this because who would ever do
such thing?
Even if nethack is meant to support compilers that do not know about
inline functions, this one was frankly too long to be a macro already,
and I'm about to make it longer still.
Program terminated with signal SIGSEGV, Segmentation fault.
77 ../sysdeps/x86_64/multiarch/strlen-evex.S: No such file or directory.
(gdb) bt
at glyphs.c:419
at glyphs.c:173
op=0x5a34af30a574 "DECgraphics") at options.c:3418
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
