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.
Asking curses to report whether the Ctrl key was being pressed during
a mouse click was sending mouse position reports--even those aren't
being requested--and actual Ctrl+Left_click was reporting a pair of
duplicate Ctrl+Mouse_position_report events when a click was actually
performed. So turn off Ctrl key reporting.
Mac with one-button mouse can be configured to send "secondary click"
for Ctrl+Click. A laptop trackpad handles that differently (press the
button while two fingers are on the touchpad to send secondary click)
and doesn't support Ctrl+Click as an alternate way to do that. If this
would work within curses then they could operate the same regardless
of how the user set the mouse or trackpad configuraiton. But I wasn't
able to make it work right.
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.
With 'popup_dialog' On, a prompt which exactly fills the available
width would start the next line with a space (to separate the prompt
from user's answer) and then have the cursor waiting after it. That's
unlike other behavior in the curses interface where the line split
would be instead of the separating space rather than in addition to it.
Old:
|long prompt?|
| X__________|
New:
|long prompt?|
|X___________|
where the X represents the cursor sitting over the start of blank space
waiting for user's answer.
Highlighting via attributes got broken three months ago. May or
may not have been noticeable depending upon which attributes are
supported. Too many variations of attribute designations...
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.
With 'popup_dialog' On, a one line popup with question and likely
responses and default answer was shown, but without having the
cursor displayed at the end of emphasize that it was waiting for an
answer. Make the popup be one character wider so that there is room
to show the cursor. No effect when 'popup_dialog' is Off and prompts
are shown at the bottom of the message window; those already have the
cursor sitting at the end.
Make final inventory disclosure use a full width menu instead of
the default 38-column width with lots of wrapping. Also, increase
that default from 38 to 40 for the rest of the time. Commit
9f6588af49 made the 38 vs 40 portion
matter much less but I decided to keep it in anyway.
When a menu or 'things that are here' popup has only a couple of
lines and they happen to be narrow, a sized-to-fit window isn't
always easy to spot when it is shown over the ends of old messages
rather than over the map, even with a border box around it. Give
such windows a minimum size of 5x25 so that they always stand out
enough to be immediately seen. This will cause more message text to
be rewritten occasionally (after dismissing the menu or text window)
but the curses interface seems to discount that as something to be
concerned about.
Fully support the mouse_support option for curses, via 'O' as well as
via config file. At the moment, mouse_support:1 and mouse_support:2
are equivalent.
Also, fix the screen-to-map coordinate translation. When the mouse
is active and over the map, the pointer's cursor becomes a cross-hair
(may very by platform) and the character cell chosen for a click
seems to be a few pixels to the right of the center of the '+'.
