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.
The prior fix for this was a bit flawed. It was only considering
the length of the last field, but what it really needed to do was
consider the placement of the last character of the last field
on the row relative to the placement of the last character of
the last field on the row previously.
If the new placement of that last character of the last field
is left of the previous placement, some clearing must be done.
The pointer could go out of bounds when decremented if it was pointing
at the start of the status_vals[BL_HUNGER] (empty string).
Also, guard tty_status_update() from an out of range index being
passed to it (botl shouldn't do that, but...).
The legal 1st parameter values for tty_status_update() in 3.6.2 are
BL_RESET (-2)
BL_FLUSH (-1)
BL_TITLE ( 0)
...though to...
BL_CONDITION (22)
count MAXBLSTATS = (BL_CONDITION + 1)
There's a BL_CHARACTERISTIC (-3) defined in the botl.h header file,
but it is not used in wintty.c and is now screened out along with
everything lower and everything MAXBLSTATS and above.
closes#142fixes#141
Like BL_FLUSH, only send BL_RESET if the window port has
indicated it wants them via setting the appropriate WC2
bits in its window_procs structure. Update documentation.
Change the placement of the code that makes a replica of the
current status fields for later comparison.
A loop shortcut was causing it to be skipped under some
circumstances and that was negatively impacting the placement
of status field values that were further to the right.
This adds BL_RESET to status_update to send a flag to a window
port that every field should be updated because something has
happened in the core to make current values shown to be
untrustworthy or potentially obliterated.
That is now distinguished from BL_FLUSH, which now has no
bearing on whether every field needs to be redone, and instead
can be used by a window port indicator that it is time to render
any buffered status field changes to the display.
tty port now sets WC2_FLUSH_STATUS indicator for BL_FLUSH support
and now does one rendering per bot() call, instead of up to 22.
Side note: The tty hitpoint bar code was relying on the old
behavior of redrawing everything upon BL_FLUSH apparently, so it
initially had some color change lag issues, corrected by marking
BL_STATUS as dirty (in need of updating) in tty_status_update()
whenever BL_HP was marked as dirty.
tty: turn off an optimization that is the suspected cause of Windows reported
partial status lines following level changes. It was turned on for
non-unix platforms only
With TEXTCOLOR disabled, compiler warnings about term_start_color()
and term_end_color() not being declared were followed by link failure
because they weren't available.
This tries to simplify color handling in the tty status code without
resorting to #if TEXTCOLOR (the proper fix, but somewhat intrusive).
For the usual case where TEXTCOLOR is defined, there were instances
of
if (color != NO_COLOR && color != CLR_MAX)
term_start_color();
...
if (color != NO_COLOR)
term_end_color();
and also of
if (color != NO_COLOR)
term_start_color();
...
if (color != NO_COLOR)
term_end_color();
I've changed both types to be
if (color != NO_COLOR && color != CLR_MAX)
term_start_color();
...
if (color != NO_COLOR && color != CLR_MAX)
term_end_color();
so that start/end pairing will always be consistent.
Also, ((color_and_attr & 0xFF00) >> 8) might not work as intended if
using 16-bit int and color_and_attr happened to have its sign bit set.
Change to ((color_and_attr >> 8) & 0x00FF) to ensure just the desired
bits.
Also also, a couple more formatting bits.
Started by removing two or three unused variables, ended up cleaning
up a lot of formatting (tabs, trailing spaces, indentation, a few
wide lines, 'if (test) return' on same line). Marked some static
functions as static in their definitions instead of leaving it hidden
in their prototypes. Moved a pair of short-circuit checks to skip
several initializations.
When a getlin() response is being typed, it wraps to second line if
the cursor tries to go past COLNO-1, but if a previous response is
treated as part of the prompt, using pline() to write prompt+space+text
wraps at a whole word boundary. tty's getlin() assumes that the screen
position can be derived from that prompt+space+text_so_far but that
doesn't match if wrapping at a word boundary leaves blank space at end
of the top line.
When a prompt is accompanied by default answer, output the answer
separately instead of pretending it is part of the prompt. Line-wrap
should occur at same point as when it was originally typed and avoid
the confusion about how far to back up when deleting characters.
This hasn't been exhaustively tested but it seems to work correctly
for ordinary input, input erased one character at a time, and input
killed all at once. One thing which definitely hasn't been tested is
having the prompt itself be so long that it needs to wrap.
After about the third time typing '#' and getting a prompt of "# K", I
decided that it wasn't clumsy typing. The call chain for get_ext_cmd()
was passing an uninitialized output buffer to [hooked_tty_]getlin()
which treated random junk as the previous result to be used as current
default. Other interfaces may need a similar fix.
ensure tty_curs() behaves the same whether DEBUG defined or not
when it comes to positioning the cursor.
The return statement, in the debug case only, was preventing
the cursor from being moved following a range check, so the
next output was written whereever the cursor happened to be
previously.
The messaging that detects the failed range check will get
written in the DEBUG defined case hopefully allowing resolution
to the range check failure, but now the cmov will still
be attempted just as it is in the case where DEBUG is not
defined.
Before this change, more-prompts and input text -prompts could not
be accepted with carriage return. Now, just like in menus, carriage
return is treated the same as a newline.
To test, use 'stty -icrnl'
When built without STATUS_HILITES, don't treat highlighting options as
if they were unknown. This may need some tweaking; the feedback feels
a bit intrusive so perhaps 'statushilites' and 'hilite_status' should
just be ignored when not available.
'hitpointbar' now relies on wc2 handling instead of being conditionally
present.
