In nethackw, there can be conflicts between menu accelerators and an extra
choice accelerator. For example, when engraving the using fingers options
conflicts with the unselect all menu accelerator. The extra choice
accelerator should take precedence.
From Bart...
Modified build configuration to use latest SDK available by default.
This change will eliminate the need for us to hard code an SDK
version into our configuration file and will eliminate the need
for developers to set the SDK version when they do not have the
matching SDK version installed. Updated the Install.nt file removing
the mention of having to set the SDK version.
Alex wrote: in nethackw, getlin clears message
window, so any unread messages are scrolled off the screen without
"--more--" prompt. If vary_msgcount is set to 1 and "potion shatters", it
is not easy to see the effect to name the potion correctly.
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'
