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
The 0x1000000 bit (NH_BASIC_COLOR bit) was used to mark
CLR_BLACK when storing it in u->ucolor. Now, all of the basic CLR_*
colors are stored that way.
The NH_BASIC_COLOR bit indicates that the value in u->ucolor is
not an rgb value, rather it is one of the 0-15 basic NetHack colors.
The window-ports need to strip the NH_BASIC_COLOR bit off before using
it for color changes.
Add options 'showvers' (boolean) and 'versinfo' (numeric mask) to
show nethack's version on the status lines during play. It won't be
particularly interesting to ordinary players but should be useful
when making screenshots or video to be streamed, or for someone who
switches between git branches or between nethack and variants.
I worked on this several months back but it was combined with
unfinished changes to 'hitpointbar'. I've separated it out so that
it can be put into use. When enabled, one or more components of
"<name> <branch> <version>" will be shown right justified after
status conditions. At present the default is "<branch>" if that is
available and overall status isn't 'released', or "<version>" if
'released' or if branch isn't available. That might need some
refinement.
It works as intended for tty and curses, although some abbreviation
mechanism would be useful if/when the program resorts to abbreviating
status conditions to make things narrow enough to fit.
For X11, it works ok for fancy_status:True (the default, controlled
via NetHack.ad settings) but is messed up for tty-style status. The
text is positioned correctly but there are gaps in it, making it
appear garbled, similar to what I saw when I tried and failed to
implement statuslines:3 for X11. [It might be due to having empty
condition widgets be 1 pixel wide instead of being totally removed
but I don't think the situation is that simple.]
For Qt, if the text needs to be truncated in order to fit, the center
portion of the string will be shown, discarding parts from the left
and right. That ought to discard from left and retain rightmost
portion instead.
For win32|mswin|Win GUI, no attempt to support it has been included.
Things should be ok when 'showvers' is left as False (the default)
but I don't know what will happen if that gets toggled to True. At a
minimum, the version info won't be right justified. The information,
or at least some of it, is displayed in the game window's title bar
so there isn't any pressing need to add it to status, but toggling
the option will need to behave sensibly if it doesn't already.
DUMPLOG requests the DUMPLOG feature as it does now
DUMPLOG_CORE requests the internal buffering only (used for CRASHREPORT)
This allows CRASHREPORT to access recent messages without performing
any file I/O.
If a termcap entry for ending attributes and color also contains
the code to switch from secondary font back to primary (HE_resets_AS
hack), maybe strip the AS code out of HE (and clear the HE_resets_AS
flag) when setting up DECgraphics. Affects whether nethack sends
extra AS sequences while rendering a run of VT line-drawing chars.
My HE doesn't reset AS so that aspect hasn't been exercized.
When switching back and forth between normal and line-drawing,
defer the switch away from line-drawing if the character will be
rendered the same in both character sets (uppercase letter, digit,
most punctuation). That might just defer the AE, but could skip it
and next AS depending on what characters are written. The cycle
might repeat an arbitrary number of times, avoiding sending many
AS+AE combinations rather than just one.
Both of these optimizations are pretty small but reducing the number
of characters sent from a server to a remote user is worthwhile.
Add a comment about something that occurred to me when fixing the
^C-during-DECgraphics-output situation several days ago. I don't
think there's any compelling reason to avoid this optimization, but
this only describes it without actually implementing it.
For tty, if ^C interrupt occurred while the terminal was displaying
VT line drawing characters, it wouldn't finish updating the map and
switch back to regular characters, so the "Really quit?" prompt was
illegible.
Rather than muck about with the signal handler, just add a fixup to
tty_putstr() since prompting ultimately uses putstr(WIN_MESSAGE).
Reproducing the situation isn't straightforward; I didn't even try.
The change 3 weeks ago for #4059 (to fix tty perm_invent memory leak)
resulted in nethack crashing during exit if built with TTY_PERM_INVENT
enabled and ending the game when perm_invent window isn't displayed.
This exits cleanly with or without perm_invent being shown and avoids
the memory leak which triggered the prior change.
As part of the tty resize handling revision, code dealing with the
perm_invent window was moved out of tty_destroy_nhwindow() was moved
into a separate routine. The new routine would have been called for
a window of NHW_PERMINVENT, but WIN_INVENT doesn't have that type,
just ordinary NHW_MENU, so the cleanup wasn't happening, resulting in
a memory leak.
I think this fixes all problems with the boundary boz drawn around
perm_invent. Also, if you enabled perm_invent in inuse_only mode
while there are already more items in use than would fix in the
available number of lines, it wasn't switching to two columns until
the next update_inventory(). And the new color handling wasn't
incorporate into tty_refresh_inventory() so after a corner window
clobbered some of perm_invent, it got redrawn but without color,
again until the next update_inventory().
With any luck this fixes more bugs than it introduces....
Make term_start_color() more versatile. If it gets passed NO_COLOR
then it performs term_end_color(). Should be able to streamline
some of the color handling this way although this hasn't done so.
Features like menucolors and so forth, are now done in the
core, and passed to the window interfaces via add_menu().
TTY_PERM_INVENT was disregarding the passed color value.
That can be turned off by the option !menucolors.
If a way to turn off menucolors in TTY_PERM_INVENT (or
perhaps in any perm_invent implementation), while keeping
it on for other menus, then a new option will be required.
Revise the tty permanent inventory window's in-use mode to be able to
switch back and forth between one full width panel and two side-by-side
half width panels on the fly as needs dictate.
A lot of trial and error involved but I think it has reached a state
where it is reliable, and the smaller number of lines required at
present can probably be viable for actual usage. At the moment it
requires at least 10 extra lines below the standard tty mesg+map+stat
display, 34 lines total for statuslines:2 or 35 for statuslines:3.
The top and bottom of the 10 or more extra lines get drawn as boundary
lines using wall characters, leaving 8 lines for full width or 16 half
lines when 8 isn't enough. If more that 16 items are in use (maybe
lots of lit candles forced into separate inventory slots or a
menagerie on leashes), the excess get skipped. However, it will use
more lines if they are available. Prior to a few days ago it was
requiring 17 extra lines and able to show 15 items as full lines only,
unable to take advantage of more lines when available.
Allow perm_invent to be enabled with 1 less line when statuslines==2
by not reserving a line for statuslines==3. If the player changes
that from 2 to 3, the perm_invent window is torn down and repositioned
one line lower if that will fit. If it won't fit, it won't reenable.
Temporarily(?) allow perminv_mode==InUse to be enabled with room for
only 8 lines instead of requiring 15. It will use more than 8 if are
more rows.
8 happens to be the amount (via 1+21+3+(1+8+1)) that will fit within
35 lines which is the biggest I can make fit on may laptop without
switching to a smaller font. Switching is a nuisance, worse than that
for the font tiny enough to fit the full perm_invent.
ToDo: if in-use won't fit in the number of lines allotted, switch to
two columns before resorting to ignoring the excess.
Maybe: allow fewer lines for full perm_invent too and use the '|'
command to scroll them. Might be too clumsy to be worthwhile.
The ability to use ^P from within a TTY getlin prompt didn't work with
msg_window:combination: it's a combination (unsurprisingly) of 'full'
and 'single', but hooked_tty_getlin() was treating it like 'full': i.e.
expecting everything to be displayed at once, with doprev_message()
returning only once the user was finished reading. I didn't even know
^P was supposed to be accessible from a getlin prompt until Pat's recent
commit 5120764, because I have always used msg_window:combination -- I
had come up with a system where I'd name a potion thrown at me "xx",
check the previous messages with ^P, and then rename it from the
discoveries list. This will be a lot easier!
With CLIPPING disabled you should need a terminal or window with at
least 25 lines to change the 'statuslines' option from 2 to 3, but
it was being allowed on tty when there were only 24 lines available.
I think the other interfaces always have clipping capability enabled
so aren't affected.
Not many level maps extend to the bottom row (line 22 for a 1-based
count) so it wasn't likely to be noticed during play. That points
that maps which don't use all rows and/or all columns could get by
without clipping by adjusting their position. However, implementing
adaptive clipping is not something that I'm going to try to tackle.
Issue reported by entrez: on tty, ^C while a menu was open followed
by 'yes' to "Really quit?" would lead to a bad window panic.
Brought on by screen erasure changes included with recent SIGWINCH
(window resize signal) changes.
Closes#1145
'm O' is a prime candidate for using ':' to select a menu item since
you can use that to avoid scrolling through many pages, but typing ':'
would immediately overwrite two or three lines of the menu with a
status refresh. curses doesn't suffer from this problem. X11 and Qt
show menus in separate windows do don't either. Not sure about WinGUI.
I think that this may have been reported in the past, but if so I don't
recall by whom, or why it wasn't addressed.
This implements the mechanics to use the ctrl_nhwindow() interface
capability to pass down a setting change from the core to the active
window port, without resorting to accessing a core global variable
from within the window port, and without altering the interface..
The passed setting is honored in the tty and curses window ports.
X11 and mswin receive and store the values, but no implementation
to change the menu prompt style is there yet.
Qt does not store the values or have an implementation.
The setting change is done in allmain.c immediately after
creating the WIN_INVEN window.
Remove menu_color support from the window port side of the interface.
The window port just has to honor the color parameter that was added
to the add_menu() interface definition in June 2022 commit
2770223d10, and let the core-side of
the interface handle things.
To that end, this does the following:
Removes the #define of add_menu() from include/winprocs.h and add a
real core-side add_menu() function to windows.c which acts as a
trampoline to the window port win_add_menu() function, while providing
a single location to adjust the parameters passed to the window port
function. get_menu_coloring() is now called in there.
Moves get_menu_coloring() from options.c into windows.c and makes it
static.
Removes all the calls to get_menu_coloring() from the tty, Qt, X11,
curses, and win32 interfaces and adjusts their code to simply honor
the color parameter in add_menu, similar to what the menu_headings
change from earlier today did.
../win/tty/wintty.c: In function ‘set_item_state’:
../win/tty/wintty.c:1174:9: warning: implicit declaration of function
‘term_start_color’; did you mean ‘term_start_attr’?
[-Wimplicit-function-declaration]
1174 | term_start_color(item->color);
| ^~~~~~~~~~~~~~~~
| term_start_attr
../win/tty/wintty.c:1178:9: warning: implicit declaration
of function ‘term_end_color’; did you mean ‘term_end_attr’?
[-Wimplicit-function-declaration]
1178 | term_end_color();
| ^~~~~~~~~~~~~~
| term_end_attr
Instead of just accepting an attribute, it's now possible to
use a color, or both color and attribute, for example:
OPTIONS=menu_headings:inverse
OPTIONS=menu_headings:red
OPTIONS=menu_headings:red&underline
Default is still just inverse.
This lets the player change the menu heading color without
needing to use menu colors for them.
Also makes it so the core uses NO_COLOR instead of 0, for all
the menu lines which don't have any prefedefined color.
Tested for tty, curses, x11, qt, and win32
Add a new option 'perminv_mode' to augment perm_invent. It handles
the same choices as the temporary TTYINV method: show all items other
than gold, show full inventory including gold, or only show in-use
items (similar to the '*' command).
For tty, both the all-except-gold and full-inventory modes can add
the poorly named 'sparse' variation which populates unused slots in
its fixed grid with the inventory letter that would go in each.
For others, the default has been changed from full-inventory to
all-except-gold. Note that gold is treated as part of 'all' or of
'in-use' if it is quivered because having the amount be shown on the
status line doesn't make that redundant.
Changing the default may mess up WinGUI if it assumes that perm_invent
is full inventory with gold.
Initially I was going to change perm_invent into a compound but this
leaves it as an on/off toggle and adds perminv_mode as a separate
option for how to show the inventory when the toggle is on. It may
make sense to combine them since dual controls is a little confusing,
but right now setting perm_invent On when perminv_mode is 'none'
changes that to 'all' and changing perminv_mode away from 'none' when
perm_invent is Off toggles it to On.
Guidebook.mn has been updated but as usual Guidebook.tex is lagging.
Gold can be quivered but not wielded, so remove the reference to the
latter. Inuse-only mode gets passed lamps and leashes when they're
actively used, so remove the reference to that being different from
Qt's paperdoll. (It is actually different, but not because they
won't be shown as in-use. The paperdoll only shows one of each but
inventory of in-use items might have more than one of either or both.)
Add a what-if comment to tools_in_use().
and reimplement 'sparse' mode (TTYINV=2 or TTYINV=3).
When hero had no inventory except for gold and perminv display mode is
ignoring gold, the header said "empty" when "only gold" was intended.
Sparse mode populates perminv with inventory letters in the unused
slots instead of leaving them blank. (The core doesn't need to be
aware of that since it doesn't affect what display_inventory() sends
to the inventory menu.)
My repository got out of synch and I had a hell of a time restoring
sanity.
The most recent commit included a line in wintty.c that shouldn't have
been there.
