If a container holds anything that a shop wouldn't ordinarily
buy and sell and you sell it for gold, the 'foreign' contents
are marked no_charge and hero still owns them. But selling the
same container+contents for credit instead of gold would take
shop possession of all the contents without increasing the
credit amount.
The fixes entry is longer than the fix. It solves cited case but
I won't be surprised much if it messes up some other case(s).
About 5 weeks ago, commit e4106bb161
changed Qt's searching in text windows to be able to find a match
on the very first line. It assumed that the first line would be
the current line except when repeating the same search after a
match. But after a failed search the current line index is -1 and
starting a new search would crash trying to look that line up.
The '/' command's variants /o, /O, /m, and /M use spaces to
align output in columns and that looks quite bad if rendered in
a proportional font. Qt normally uses proportional font for
text windows but it watches the supplied lines for any with four
consecutive spaces and forces fixed-width font if it sees any.
So changing the existing separator line from "" to " " makes
Qt format the dowhatis data as intended.
'? k' shows menu controls in a fancy layout and '? i' lists the
same things in basic layout but both only showed the keys that
can be changed via option settings. Add <return>, <space>, and
<escape> so that all relevant keys are listed together whether
re-bindable or not. The description of <space> is accurate for
tty and curses but possibly not for other interfaces.
This also reorders how the controls are listed, moving next page
and previous page before first page and last page, and placing
invert between select and deselect rather than after both.
number_pad==1 adds
'5' => 'G'
M-5 => 'g'
'0' => 'i'
number_pad==2 swaps 5 and M-5 and adds M-0
'5' => 'g'
M-5 => 'G'
'0' => 'i'
M-0 => 'I'
M-5 and M-0 were missing from the bound key handling; they still
used hardcoded digits even though the actions for plain 5 and
plain 0 can be bound to other keys these days. This implements
the M-5 variation as NHKF_RUSH2. Changing numpad from 1 to 2
or vice versa will swap the NHKF_RUN2 and NHKF_RUSH2 actions
regardless of what keys they're assigned to. I haven't done
anything for unimplemented NHKF_DOINV2 though (and am not
planning to in case someone else wants to jump in...).
This also fixes the description of the 'I' command. The extended
command name for that still misleadingly refers to "type" rather
than "class" though.
When ?i shows key bindings, at the end of each group (movement,
prefixes, general, game, debug) report any commands for that
group which don't have any key assigned. Movement and prefixes
all have keys; they'd be pretty useless without and key bindings
won't override movement commands. For general, the "keyless" are
|#exploremode
|#herecmdmenu
|#therecmdmenu
after this adds the relevant flag to their command definitions;
for game, "#terrain" is the only one; the debug section has 20.
There is a known problem that I've going to pretend that I didn't
notice: if I use BIND=D:takeoffall then 'A' becomes unassigned,
'D' invokes #takeoffall, "#droptype" becomes keyless, and ?i
reports those correctly. But if I use BIND=M:takeoffall, 'A'
becomes unassigned, 'M' continues to be its usual prefix, and
the "#takeoffall" command is nowhere to be seen. The code that
tracks assignments is letting that case fall through the cracks.
'M' ends up assigned to both and the ?i code deliberately only
shows the first.
