Submitted for 3.7.0; all but one also apply to 3.6.3.
I rewrote the curses terminal-too-small message instead of just
fixing the spelling of "minumum".
When we were saving message history as part of a game save for insurance,
we were calling remember_topl() and thus inappropriately changing topline
state. This would cause us to mis-manage the topline in subsequent calls
to update the topline.
The code has been re-worked to fix the issue, reduce complexity and make
the code clearer.
When we save gamestate as part of making an insurance snapshot, we will
save message history which will clear toplines but leaving window state
in tack including the need for more.
When fuzzing, we would increment ttyDisplay->inmore but then prematurely
exit more() leaving ttyDisplay->inmore set.
Under various conditions, we can request to remember the topline when
the topline had not yet been acknowledged leaving toplin state in an
inappropriate state.
Messages on tty which bypass message history weren't handling long
lines properly. If the text wrapped to line 2, that continuation
portion was left on the screen after whatever operation that put it
here was finished. (To reproduce: assign a long name to a monster
with a long type name so that the combined length exceeds the display
width, then move the cursor over it with ';' or '/' while autodescribe
is On.)
This time prompting isn't adversely affected.
This effectively reverts 1ad2415315
because it was interfering with prompts that spanned more than one
line (by inserting '--More-- + erase' between displaying of prompt and
getting input for the answer).
So we're back to the situation where autodescribe feedback when moving
the cursor will leave text on the second line if it generates text too
wide for one line. (^R redraws the screen correctly.)
Messages on tty which bypass message history weren't handling long
lines properly. If the text wrapped to line 2, that continuation
portion was left on the screen after whatever operation that put it
here was finished. (To reproduce: assign a long name to a monster
with a long type name so that the combined length exceeds the display
width, then move the cursor over it with ';' or '/' while autodescribe
is On.)
Noticed while testing the history suppression: if you have DECgraphics
enabled and look at a graphics character on the map, the topline shows
x description of x
where 'x' is displayed as it appears on the map (line drawing char).
^P for msg_window:single knows about that and reproduces the effect if
you recall such a line. But msg_window:full/combination/reverse didn't
know about that and dumped it as-is into text output, ending up with a
strange 8-bit character for 'x' instead of the line drawing one.
I think other rendering schemes will be unaffected by this. It's just
duplicating what is done for msg_window:single.
Extend 'putstr(WIN_MESSAGE, attribute, string)'s attribute so that
'custompline(SUPPRESS_HISTORY, ...)' can work with ^P's message
history like DUMPLOG history, in order to keep autodescribe feedback
and intermediate prompts for multi-digit count ('Count: 12', 'Count:
123') prompts out of recall history. The old autodescribe behavior
could easily push all real messages out of the recall buffer when
moving the cursor around for getpos, and the count behavior looked
silly for a four or five digit gold count if you set the msg_window
option to 'full' or 'combination' and viewed them all at once.
Other interfaces may want to follow suit, but this doesn't force them
to make any changes. I added a hook for "urgent messages" that might
be rendered in bold or red or some such and/or override the use of
ESC at --More-- from suppressing further messages, but there aren't
any custompline(URGENT_MESSAGE, ...) calls (potentially "You die...",
for instance) to exercise it. Other people have implemented similar
feature it different ways and I'm not sure whether this one is really
the way to go since the core needs to categorize each message that it
deems to be urgent. MSG_TYPE:stop may be sufficent, although MSG_TYPE
matching can entail a lot of regexp execution overhead at run-time.
Add code to run a fuzz tester, simulating (more-or-less) random
keyboard mashing. There's no option to turn it on, you need to
set iflags.debug_fuzzer on via a debugger or something along
those lines.
I couldn't reproduce the reported problem of the "In what direction?"
being issued after the screen was cleared, but bypassing pline() in
favor of putstr(WIN_MESSAGE) for tty prompts did also bypass
if (vision_full_recalc) vision_recalc(0);
if (u.ux) flush_screen(1);
done in pline(). Inadvertent loss of the latter could conceivably be
responsible for the problem. If so, the escape code used by cl_end()
may be broken for somebody's termcap or terminfo setup since clearing
to the end of the line in the message window shouldn't erase the rest
of the screen.
Regardless, the prompting change also bypassed the ability to show
the prompt with raw_printf() if the display wasn't fully intialized
yet, so some change to the revised prompting was necessary anyway.
Switching back from putstr(WIN_MESSAGE) to pline() resulted in
duplicated entries in DUMPLOG message history, one with bare prompt
followed by another with response appended, so more tweaking was
needed. The result is use of new custompline() instead of normal
pline(). custompline() accepts some message handling flags to give
more control over pline()'s behavior. It's a more general variation
of Norep() but its caller needs to specify an extra argument.
Update DUMPLOG's message history to include player responses to
most queries. For tty, both getlin() and yn_function(). For other
interfaces, only yn_function() is covered. (It's intercepted by a
core routine that can take care of the logging; getlin() isn't.)
Also includes saved messages from previous session(s), for the
interfaces which support that (tty), to fill out the logging when
a game ends shortly after a save/restore cycle.
The tty interface was using pline() to display prompt strings.
Having 'MSGTYPE=hide "#"' or 'MSGTYPE=hide "yn"' in .nethackrc
would suppress many prompt strings (in the two examples mentioned,
entering extended commands or the vast majority of yes/no questions,
respectively) and generally lead to substantial confusion even if
done intentionally, so switch to putstr(WIN_MESSAGE) instead.
Reported directly to devteam last October, for 3.4.3 on NAO,
subject "UI flaw in message history":
"Applying the stethoscope at self informs:
"Status of Xxxxxxxx (piously neutral): Level 14 HP 138(138) AC -15, very
"fast, invisible.--More--
This is reproducible with shorter character name "wizard" by being
"nominally neutral" or "nominally chaotic". I had a 2 digit level
but didn't notice that my AC took up only 1 digit and ended up
using 125ish blessed potions of full healing to get 4 digits of hit
points in order to get the line to wrap between "very" and "fast".
"But the message history with Ctrl-P shows:
"Message History
"
"Status of Xxxxxxxx (piously neutral): Level 14 HP 138(138) AC -15, very
"invisible.
The key was "Message History", indicating msg_window:full or other
setting which causes ^P to bypass the top line message window and
use a general text window to deliver all history lines at once.
The original feedback splits the line by replacing the space
between "very" and "fast" with a newline, which topline handling
notices and processes as special, but then leaves in place.
msg_window:full results in tty_putstr() case NHW_TEXT, which treats
newline as an ordinary character since it doesn't expect to see
that in text. Squeezing out three doubled spaces made room for
"very\nfast," on the top line. process_text_window() attempted to
write it there, but putchar() wrote up through "very," on one line,
then output the newline which resulted in "fast," on the next line.
Then explicit cursor positioning set things up to put "invisible"
at the start of that line, overwriting "fast," so making it appear
to be missing.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
