The two options are very similar but probably mutually exclusive
except when using look-here and look-into-container (both via ':')
with the default setting for 'sortloot', or with inventory when
'sortpack' has been toggled off.
This removes 'use_menu_glyphs' and changes 'menu_objsyms' from a
boolean to a compound taking six possible values:
| 0: no object symbols in menus,
| 1: append object class symbol to object header lines (same as old
|menu_objsyms boolean),
| 2: include object symbol in menu entry lines for objects (same as
|recently added use_menu_glyphs),
| 3: both 1 and 2,
| 4: display as #2 but only if the menu lacks class header lines,
| 5: if header lines are present, display as #1; if headers are not
|present, then display as #4 (which will implicitly be #2).
Default is #4.
Effectively replaces the options portion of pull request #1406 and
retains the functionality, but not as default for normal menus.
Guidebook.tex is only partially updated. Someone else will need to
finish that.
There was a transcription error in the comments in cstd.h for
the standard list of header files, where only the description
remained for <stdlib.h>, not the name of the file itself.
Remove several extraneous inclusions of the standard C99 headers.
Tested on the following afterwards:
Linux (using hints/linux.370) including tty, curses, qt6, and X11
macOS (using hints/macOS.370) including tty, curses, qt5, and X11
Windows MSYS2 using sys/windows/GNUmakefile
Windows Visual Studio using sys/windows/Makefile.nmake
msdos cross-compile on Ubuntu using djgpp cross-compiler
gcc has recognized various "magic comments" for white-listing
occurrences of implicit fallthrough in switch statements for
a long time:
The range and shape of "falls through" comments accepted are
contingent upon the level of the warning. (The default level is =3.)
-Wimplicit-fallthrough=0 disables the warning altogether.
-Wimplicit-fallthrough=1 treats any kind of comment as a "falls through" comment.
-Wimplicit-fallthrough=2 essentially accepts any comment that contains something
that matches (case insensitively) "falls?[ \t-]*thr(ough|u)" regular expression.
-Wimplicit-fallthrough=3 case sensitively matches a wide range of regular
expressions, listed in the GCC manual. E.g., all of these are accepted:
/* Falls through. */
/* fall-thru */
/* Else falls through. */
/* FALLTHRU */
/* ... falls through ... */
etc.
-Wimplicit-fallthrough=4 also, case sensitively matches a range of regular
expressions but is much more strict than level =3.
-Wimplicit-fallthrough=5 doesn't recognize any comments.
Plenty of other compilers did not recognize the gcc comment convention,
and up until now the compiler warning for detecting unintended
fallthrough had to be suppressed on other compilers. That's because the code
in NetHack has been relying on the gcc approach, and only the gcc approach.
The C23 standard introduces an attribute [[fallthrough]] for the
functionality, when implicit fallthrough warnings have been enabled.
Several popular compilers already support that, or a very similar attribute
style approach, today, even ahead of their C23 support:
C compiler whitelist approach
--------------------------- -------------------------------------
C23 conforming compilers [[fallthrough]]
clang versions supporting
standards prior to
C23 __attribute__((__fallthrough__))
Microsoft Visual Studio
since VS 2022 17.4.
The warning C5262 controls
whether the implict
fallthrough is detected and
warned about with
/std:clatest. [[fallthrough]]
This adds support to NetHack for the attribute approach by inserting a
macro FALLTHROUGH to the existing cases that require white-listing, so
other compilers can analyze things too.
The definition of the FALLTHROUGH macro is controlled in include/tradstdc.h.
The gcc comment approach has also been left in place at this time.
First noticed this when watching someone livestream, and managed
to figure it out from there: The window that pops up when looking
at a pile of objects under you by pressing ':' is marked as a menu,
but has no selectable options. Curses still allowed you to use the
menu-search command (':') on it.
Prevent the menu search command in windows with no selectable entries.
Reported by ars3niy, the curses interface could behave strangely on
the first turn if the 'pauper' option/conduct was specified.
There isn't any definitive flag indicating whether or not the game
has started. Since 'moves' has traditionally been initialized to 1
rather than to 0, there were several instances of
| if (moves <= 1 && invent != NULL)
being used to determine the starting state on the assumption that
once hero has inventory, the game has begun. Introduction of the
'pauper' option made the test for non-Null invent become unreliable.
For paupers, the program would behave as if the game hadn't started
yet until the player finally made a time-consuming move.
This changes compile-time initialization of 'moves' from 1 to 0,
then sets it to 1 when initial inventory would be bestowed (even
when 'pauper' inhibits that). That's probably not the best place
for it, but testing for 'moves==0' now should produce an identical
effect as 'moves<=1 && invent!=NULL' used to accomplish.
It would have been much simpler just to give paupers 1 gold piece,
or perhaps one rock, in place of usual starting gear so that their
initial inventory wouldn't be empty, but the moves+invent way of
checking for start-of-play has always bothered me.
Should 'pauper' be preventing 'nethack -X' from giving its starting
wand of wishing? Conducts and explore mode don't really overlap so
maybe it doesn't matter.
Fixes#1275
The g? structs had a mix of variables that were written to
the savefile, and those that were not.
For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.
This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.
Details:
gb.bases -> svb.bases
gb.bbubbles -> svb.bbubbles
gb.branches -> svb.branches
gc.context -> svc.context
gd.disco -> svd.disco
gd.dndest -> svd.dndest
gd.doors -> svd.doors
gd.doors_alloc -> svd.doors_alloc
gd.dungeon_topology -> svd.dungeon_topology
gd.dungeons -> svd.dungeons
ge.exclusion_zones -> sve.exclusion_zones
gh.hackpid -> svh.hackpid
gi.inv_pos -> svi.inv_pos
gk.killer -> svk.killer
gl.lastseentyp -> svl.lastseentyp
gl.level -> svl.level
gl.level_info -> svl.level_info
gm.mapseenchn -> svm.mapseenchn
gm.moves -> svm.moves
gm.mvitals -> svm.mvitals
gn.n_dgns -> svn.n_dgns
gn.n_regions -> svn.n_regions
gn.nroom -> svn.nroom
go.oracle_cnt -> svo.oracle_cnt
gp.pl_character -> svp.pl_character
gp.pl_fruit -> svp.pl_fruit
gp.plname -> svp.plname
gp.program_state -> svp.program_state
gq.quest_status -> svq.quest_status
gr.rooms -> svr.rooms
gs.sp_levchn -> svs.sp_levchn
gs.spl_book -> svs.spl_book
gt.timer_id -> svt.timer_id
gt.tune -> svt.tune
gu.updest -> svu.updest
gx.xmax -> svx.xmax
gx.xmin -> svx.xmin
gy.ymax -> svy.ymax
gy.ymin -> svy.ymin
Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
gf.ftrap, gl.light_base, gt.timer_base
curletter is screened to be in valid range in all
other switch/case branches except in the default case,
which is fallthrough.
Add check for valid range in here also, otherwise
array might be addressed with invalid offset.
This should fix the following, found
with UBSAN and #debugfuzzer:
../win/curses/cursdial.c:1558:49: runtime error: index -154 out of bounds for type 'char [256]'
0x5f3857eff140 in menu_get_selections ../win/curses/cursdial.c:1558
0x5f3857ef78c8 in curses_display_nhmenu ../win/curses/cursdial.c:801
0x5f3857edd390 in curses_select_menu ../win/curses/cursmain.c:768
curses_yn_function() was returning a value that wasn't in the
subset of legal return values. This fixes that.
The unexpected return value of 32 (or space) then brought to
light an indexing error in the core that's been there a while,
apparently since at least 3.2.0, and that caused a null pointer
dereference in a strlen() call, which is what actually caused
the crash in issue #1205. This fixes that too.
Close#1205
Redo menu sizing to eliminate one of the analyzer hacks. There's no
need to loop through the menu entries a second time to find the last
one. The first time can remember it.
Also, some routines were taking arguments with
some_function(WINDOW *win, nhmenu *menu, ...)
and others with
other_function(nhmenu *menu, WINDOW *win, ...).
Change them all to have the window pointer 1st and menu pointer 2nd.
This is mostly just adding some Null guards ahead of
code that was already dereferencing pointers, so there
should be no change in behavior.
Also adds one validation of an array index that was
drawing a complaint.
<color>
off: map, menu items, menu headings, menu prompt/title all, everything should have color suppressed.
<curses guicolor>
on: map, menu items, menu headings, menu prompt/title can all feature color, as can
menu borders, menu-selector letters.
off: map, menu headings, menu prompt and menu items (menucolors on) can still feature color,
but all other non-map features such as menu borders, menu-selector
letters will not have color.
<menucolors>
on: menu items can have colors if they match one of the regex in config
file; menu headings, menu prompt can also be in color (based on menu_headings option).
off: menu items won't have colors, but menu headings, menu prompt still
will feature colors (based on menu_headings option); those are not impacted by turning
off menucolors.
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.
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
Menus in the curses interface would honor a digit as a selector
character ("letter" :-) for PICK_ANY menus but forced it to start a
count in PICK_ONE menus. This fixes that, although the menu where I
was using digits as selectors (not included) has been changed to use
letters so this fix isn't being exercised anymore.
Also, add a couple of comments about persistent inventory.
author Ray Chason <ray.chason@protonmail.com> 1684372172 -0400
committer nhmall <nhmall@nethack.org> 1685414340 -0400
Add configuration to support Curses on WinGUI
and enable support for Unicode on Curses.
Allow NetHackW to select the Curses interface
Reorder drawing of extended command prompt
Curses on WinGUI needs this change. This may be a bug in PDCursesMod,
but it seems to be harmless to the other ports.
Avoid calling Curses after the windows are closed
Provide erase_char and kill_char for WinGUI Curses
Set Lua version to 5.4.6
In curses, selecting a partial stack, then unselecting the entry,
and then selecting it normally, the entry still kept the quantity
from the partial selection. Make it behave like all the other
windowports by resetting the quantity when the entry is unselected.
Meta-key fix for curses interface running on top of ncurses library.
Previously only digits and lower case letters would produce a meta
character when combined with Alt (or Option on Apple keyboards), now
it should work for any basic character (not arrows or other function
keys). It only works on terminals that send two characters ESC k
for Alt+k but that is not a change in behavior.
curses interface running on top of PDcurses library uses different
code which isn't fixed by this. The alt key fixup it does have was
already present in curses_read_char() and recently got duplicated in
curses_convert_keys(). At least one other routine calls the latter
so it was necessary, but curses_read_char() calls that routine so
doesn't need to keep its own copy of the fixup.
The consolidation of global variables from scattered source
files into decl.c and declared in decl.h was begun in 3.7.0.
Their placement in common files was done for centralized
initialization and potential re-initialization during a
"play again" scenario.
It wasn't really necessary for all of them to be housed in a
single huge structure to meet the "play again" requirement,
and the single huge structure has been a little unwieldy when
it comes to maintenance.
Following this commit, instead of one single extremely large structure
named 'g' to house all of the relocated global variables, they
are distributed into several ga through gz.
To make things easy for the developer, each variable is placed
into the struct corresponding to the starting letter of the variable.
That way, no lookup is required in order to know which struct houses
a particular variable, it is a simple match to the starting letter
for all the centralized global variables.
A global variable named 'amulets', would be found in ga.
ga.amulets
^ ^
A global varable named 'move', would be found in gm.
gm.moves
^ ^
A global variable named 'val_for_n_or_more' would be found in gv.
gv.val_for_n_or_more
^ ^
A global variable named 'youmonst' would be found in gy.
gy.youmonst
^ ^
Instead of using index() macro defined to strchr, use C99 strchr.
Instead of using rindex() macro defined to strrchr, use C99 strrchr.
If you want to try building on a platform that doesn't offer those
two functions, these are available:
define NOT_C99 /* to make some non-C99 code available */
define NEED_INDEX /* to define a macro for index() */
define NEED_RINDX /* to define a macro for rindex() */
This replaces the old pushq/saveq arrays (which were used to save
the keys pressed by the user for repeating a previous command)
with a new command queue. This means there's no hard-coded limit
to the saved keys, and it can repeat extended commands which are
not bound to any key.
Fix '#repeat' for tty; both it and ^A can repeat an extended command.
Fix both for curses; they can repeat an extended command instead of
just repeating the initial '#' to start getting an extended command.
X11 (tested), Qt (tested), and probably Windows GUI (not tested)
behave the same as before: ^A (or #repeat) after an extended command
just repeats the # to run the dialog to get an extended command.
I hope this introduces fewer bugs than it fixes but I don't think I'd
bet on that....
Change curses' use of menuitem_invert_test() to match the recently
changed tty behavior: when menuinvertmode is 1 the test excludes
special menu items that are flagged 'skip-invert' while handling
select-all and select-page as well as invert-all and invert-page,
and when that option is 2 then it also operates on deselect-all and
deselect-page.
Have curses catch up with tty, X11, and Qt: if a menu of objects has
any heavy iron balls, their entries can be toggled on or off by using
'0' as a group accelerator. That's been supported by tty and X11 for
ages and by Qt since yesterday. This also supports having any digit
as a group accelerator so that the 'O' hack to pick number_pad mode by
typing the digit that matches the value description works (except for
menu entry for mode -1; '5' happens to work for that one but doesn't
match its description).
The extended command input prompt was behaving in an unintended way:
Typing #a<enter> executed #adjust. Spaces in the entry prevented matching
any command. No error message was given when no command was matched.
Fix all of those, so it behaves more like the tty.
Clean up the tty, curses, and X11 windowport code, so they don't use
the extcmdlist array directly, but query with extcmds_match
and extcmds_getentry.
Have curses call the core get_count() routine instead rolling its
own so that backspace and delete are supported. That part was
trivial to accomplish. Unfortunately it brought the disappearing
menu phenomenon back so it became more complicated overall.
This fixes the disappearing menu, but not curses menu count entry
failing to honor backspace/delete. Entering two or more digits
to get a "Count:12" message, followed by non-digit which removes
that, resulted in the menu for apply/loot in-out container operation
vanishing while it was still waiting for a choice. (Typing a choice
blindly did work.)
The code intended to handle this. I don't understand why refresh()
wasn't working. Reordering stuff didn't help until I changed that
from refresh() to wrefresh(win).
The original Count:123 display was limited to 25 characters and
menus to half the main window, so they didn't overlap. I made the
count display wider--because it is now also used for 'autodescribe'
feedback when moving the cursor around the map--so made something
that originally was impossible become possible. One line of the
menu does get erased while "Count:" is displayed, but then gets put
back by the wrefresh().
Give the window-port side of *_update_inventory() an argument.
Calls in the core still omit that; invent.c's update_inventory()
is the only place that cares.
tty and X11 honor the menu_xxx options. Qt currently doesn't
support menu manipulation by keyboard. curses does support that
but was only handling the default menu keys.
Redo the fake ESC handling for curses' wgetnstr() so that it
applies to all popup prompts rather than just to "Who are you?",
in case the player sets the 'popup_dialog' option.
