I got confused and thought that this one (actually pair) was more
complicated than it actually is. have_mixed_leadin is used in an
ordinary way, but resetting it to false happens in spots where it
can't be used again. The analyzer complains that the assignments
don't do anything useful.
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
The curses message window shows new messages bold, and removes the
bolding from older ones. The code was calling curses mvwchgat with
attribute and color parameters in the wrong order. Also change the
code to actually retain the color of the window, so it just removes
the bold attribute.
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.
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.
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
We received a report from someone whose build was failing because
of the use of cchar_t and setcchar(). They were getting errors
even though they were using an up-to-date curses library.
Apparently, ncurses requires that _XOPEN_SOURCE_EXTENDED must be
defined before the curses header files in order for those features
to be available.
We had already updated our .370 series of hints and hints/include
files with
-D_XOPEN_SOURCE_EXTENDED=1
but this person must have been building in some other way.
Instead of failing to build in that situation, allow the
fallback to the older, less-functional genl_putmixed() function,
but also try not to do so silently and display a message that
functionality is reduced.
The difference between the use of genl_putmixed() and
curses_putmixed() or tty_putmixed(), is that when doing
'/' farlook operations, curses_putmixed() and tty_putmixed() try to
display a character in the message window that looks exactly the same
as the one on the map, even if a symbol from a symset is being used
on the map, or when using ENHANCED_SYMBOLS.
Related note: curses_putmixed() matches the symbol and the color,
whereas tty_putmixed() (at present) does not attempt to match the
color.
The curses interface was using genl_putmixed() which doesn't
preserve the symbol actually used for a glyph on the display.
This is a first-attempt at implementing curses_putmixed().
On Linux you'll need to distribute the Makefiles again
sh sys/unix/setup.sh sys/unix/hints/linux.370
On macOS, you'll need to distribute the Makefiles again
sh sys/unix/setup.sh sys/unix/hints/macOS.370
This is a better workaround for the missing message window border when
when restoring with align_status:left. Unlike the previous hack, this
may even be the correct way to handle it in the first place.
I haven't tracked down when the problem started.
This fixes the missing message window border when restoring with
align_status:left (which narrows and forces that window to the right).
It can't possibly be the correct way to fix things but does work.
This was not a problem with 3.6.4 (the most recent pre-3.7 playground
I have on hand) but I don't have the energy to use 'git bisect' to
track done when it started to whether the cause is discernable. The
message history is put into place without going through putstr() so
differs from normal message handling.
In some scenarios where a message prompted a 'more' (in curses shown as
'>>'), the '>>' could overwrite the last one or two characters of the
message.
This could happen if a single message on its own was the length of the
message space minus 2 (e.g. for an 80 character terminal, "h - a concave
amulet named this is an amulet name, it is very long, and so on."), or
if an addition to an existing line brought it to the length of the
message space minus 1 or 2 (e.g. "You materialize on a different level!
You remember this level as testlevlname."). The two scenarios had
slightly different causes.
I think this fixes both of those scenarios. I believe this is the
cause of the problem described in GitHub issue #990 but there isn't
enough detail to know that for a fact.
From the newsgroup: identifying by menu pops up multiple menus in
succession if the player picks fewer invent entries than are being
granted, but the second and subsequent ones could cover up the
message window and hide the feedback from prior ones.
If multiple popup menus are needed when identifying, issue --More--
before each menu after the first. The code seemed to be trying to
do this already, but it should have used wait_synch() rather than
mark_synch(), or perhaps used display_nhwindow(WIN_MESSAGE, TRUE)
instead of either one of those. For curses, both mark_synch() and
wait_synch() were no-ops. Now they do something. X11's behavior
wasn't right either; it seemed to be lagging one message behind
(something I had noticed recently and then forgotten about; I still
don't remember the context then so don't know whether this fixes
that earlier situation).
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() */
(user-side decisions really, but as it stands right now
user-side decisions/options are made and processed by the core)
add a parameter to add_menu so color can be passed
Make sure g.hero_seq has a sane value during restore before moveloop()
has a chance to update it.
Have curses use g.hero_seq for messages delivered via putmsghistory().
Switch from 'moves' to 'hero_seq' for tracking whether consecutive
messages were issued on the same move and for whether current move
is still same one after played has responded to --More-- with ESC.
This is comparable to the recent fix for tty. When messages aren't
currently being suppressed by use of ESC at --More-- (">>" for
curses), if an urgent message itself triggers --More--, don't start
suppressing messages if player dismisses it with ESC.
This one has me baffled, first how/when it happened and then why no
one reported it. The line
current_mesg->turn = g.moves;
vanished from mesg_add_line() at some point. It is visible in diff
context of commit 99ed00012e from March,
2019 but I can't find any commit since that time which removed it.
[I've been using
git log --no-min-parents --no-max-parents --patch win/curses/cursmesg.c
and then searching within the pager. Maybe that's flaky, but if so,
things wouldn't be any less strange.]
The missing line resulted in mesg->turn being uninitialized, so when
^P compared consecutive messages to decide whether they were issued on
the same turn, arbitrary junk made them all seem to be from different
turns so "---" got inserted before every message. I suppose that if
someone uses a malloc that zeroes the memory it hands out, mesg->turn
field would always be 0 and ^P would behave as if all messages were
from the same turn, so not show any "---" separators. Then players
might not be aware that "---" between groups of messages was intended.
[The messages ought to be grouped by move rather than by turn, but
that's something the core would have to provide.]
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.
further adjustments to the window port interface to pass a pointer
to a glyph_info struct which describes not just the glyph number
itself, but also the ttychar, the color, the glyphflags, and the
symset index.
This affects two existing window port calls that get passed glyphs
and does the parameter consistently for both of them using the
glyph_info struct pointer:
print_glyph()
add_menu().
The recently added glyphmod parameter is now unnecessary and has been
removed.
groundwork only - window port interface change
This changes the last parameter for add_menu() from a boolean
to an unsigned int, to allow additional itemflags in future
beyond just the "preselected" that the original boolean offered.
There shouldn't be any functionality changes with this groundwork-only
change, and if there are it is unintentional and should be reported.
Typing ^H actually passed a 16-bit value back to the core which got
interpreted as ^G after the extra bits were discarded. I don't think
any previous changes to the curses interface caused this. It's
astonishing that no one ever noticed; the world must be full of numpad
users.
When I implemented getmsghistory()/putmsghistory() for curses I was
assuming that DUMPLOG would only be used with tty, but it is interface
neutral and can be used with curses (or others). So curses message
history needs to behave like tty message history and be sure to pass
along messages that bypass pline() and the normal message window.
(Mainly one-line summaries of long quest messages, but also old
messages fetched from a save file and available to be re-saved without
having been shown if new session doesn't generate enough new messages
to flush them.)
Turns the "fix" in commit 319dcf4746
handled removing the default answer for single-line-prompt plus
multi-line-answer but not for multi-line-prompt plus long-enough-
answer-to-reach-another-line. The logic wasn't quite right and I
misunderstood what is stored in linestarts[] so even correct logic
wouldn't have solved things.
Support user's terminal settings for erase char and for kill char.
Erase char is typically <delete> or <backspace>, both of which are
already explicitly handled so probably no effect there. Kill char
(generally ^U these days) will be honored unless it is a printable
character (don't know whether there are any troglodytes out there
who still use '@' for that...). The current handling for ESC works
the same if there is any input to kill, but yields 'cancelled' when
there isn't.
That's for message window getline(), which operates char-by-char.
The popup getline() uses a curses routine to get an entire string
and already honors kill char but treats ESC as input of ^[.
