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.
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 '+'.
Support user's terminal settings for erase char and for kill char.
Erase char is typically <delete> or <backspace>, both of which are
already explicitly handled so probably no effect there. Kill char
(generally ^U these days) will be honored unless it is a printable
character (don't know whether there are any troglodytes out there
who still use '@' for that...). The current handling for ESC works
the same if there is any input to kill, but yields 'cancelled' when
there isn't.
That's for message window getline(), which operates char-by-char.
The popup getline() uses a curses routine to get an entire string
and already honors kill char but treats ESC as input of ^[.
Right button is button3 rather than button2. Accept either and treat
both as "not left" to pass CLICK_2 back to the core.
Treat <Ctrl>+left-click as "not left" too, to simplify usage with Mac
one-button mouse (where <Ctrl>+left-click can be configured to send
"secondary click" but might not be set do so) or one-button laptop
trackpad (where having two fingers on the scrolling portion of the pad
while clicking the button is necessary to send "secondary click").
The position bars shown by curses when the map is clipped weren't
being drawn as intended (integer arithmetic). Changing parentheses
was enough to get it working, but it didn't handle the edge case
where non-zero got rounded to 0 (so when map was panned down, the
uppermost character of the vertical position bar still showed '*',
falsely indicating that top of map was currently within view.
Followup to 1c03d0970115c776d1c4791fea3c33f70b0b5378; that had been
too easy. When map was clipped and panned to the side, the highlight
for hero's spot was shown next to the '@' instead of on it.
Using ':' to have search string matching toggle items chosen for
selection would show selection highlighting on the current page for
items matched off-page.
I noticed the wrapping issue while testing out the 'bad fruit' fix,
then the other things while fixing it.
1) inventory entries too wide for narrow persistent inventory window
wrapped without any control; normally can't be seen except for the
last entry when the list is short enough to leave at least one line
available; it looked fairly reasonable with window borders Off, but
when On the last char of the first line and first char of second
line were clobbered by the border box;
2) when there were too many entries to fit within the height, those
after the last one which fit were appended to it for borders Off
(or written on bottom line and then overwritten by the border box
for borders On); noticed because the selector letter is highlighted
with inverse video, even when written at an unexpected place;
3) suppress the inverse video hightlighting of inventory letters since
they can't be selected from that 'menu';
4) for borders Off, the top line was left blank as if a border was
going to be drawn there;
5) since the entries are truncated due to the narrow window (on a
modest sized display), strip off leading "a", "an", or "the" prefix
for inventory entries (written to curses perm_invent window only);
lets a couple more characters of more interesting stuff be seen.
Most of the entries for '?' looked awful because curses was using
((terminal_width / 2) - 2) for the window width ('- 2' was to make
for for a border around the popup window, regardless of what the
'windowborder' option was set to). Splitting text that has been
manually formatted for 80 columns "worked" but looked bad when not
required.
Some of the help files are using 79 characters on a few lines,
producing wrapped text when displayed. Those would look better if
limited them to 78 or if curses can be modified to suppress the
window border when the entire display is being covered by a popup.
tty ignores map column #0 (0-based index), like the core, and draws
the map in screen columns 1 (1-based index) through 79, leaving screen
column 80 blank. curses was drawing all 80 map columns and since #0
was always unused, screen column 1 was blank and the map was shown in
2 through 80. Change curses to work like tty.
This was too easy; there may be problems lurking. One known issue: it
should be made smarter about when clipping/panning is necessary since
it thinks that a full 80 columns are needed but 79 suffice.
EDIT_GETLIN is more complicated on curses than on tty due to way that
long lines are handled....
Using ESC to get rid of the default response removed it from the
answer buffer but didn't erase back to the end of actual prompt,
making it look as if it was still there. Fixing that for a one-line
prompt+answer was needed and would have been easy but it also needs to
be prepared to go back to prior lines. Both the prompt and the answer
could conceivably span lines although in practice it will usually just
be one line or else prompt+answer combined spanning to a second line.
This hasn't been exhaustively tested been seems to be working correctly.
Fixes#197Fixes#195
Add a call to nonl() to tell curses not to convert carriage return (^M)
to newline. Line input accepts both ^J and ^M as end of line/end of
input, but the core's command processing treats ^M as "unknown command"
(by default; someone could use the BIND option to assign some command
to that character). The end result is that accidentally pressing the
<return> or <enter> key (or Ctrl+M key combination) won't make the hero
run towards the bottom of the screen as if the user had typed ^J. The
curses docs also claim that it allows more optimization during screen
updating by making ^J work as plain linefeed rather than ^M^J newline.
The tty interface can achieve this (the 'do not convert ^M to ^J part',
not the 'more optimization' part) by issuing the command 'stty -icrnl'
(on Unix or sufficiently Unix-like system) prior to running nethack,
but that has no effect when using the curses interface (at least with
ncurses on OSX where I've tested it).
A better fix would be to look up the current terminal settings at
program startup and only call nonl() if -crnl was in effect so that
curses and tty would behave the same in this regard, but curses is
supposed to let us avoid those sorts of messy details....
Fixes#193
Under curses interface, make characters which are both entry selectors
and menu commands function as a selector. Needed to support using ':'
to look inside a container when applying/looting it via menu, instead
of performing a menu search operation. (There was another case like
this but I can't remember what the circumstances are. The fix is
general enough to cover it, whatever it is.)
For menus which don't have ':' as a choice, make sure search prompt
doesn't offer garbage default input when built with EDIT_GETLIN.
Bug? If player has 'popup_dialog' option On, EDIT_GETLIN is ignored.
Plain curses I/O doesn't seem to offer a way to implement it.
After going back and forth between prompts causing message lines
to be overwritten and to be skipped, this yoyo might have finally
run out of string. Fingers crossed....
Fix a 'FIXME': don't follow a message with two spaces in anticipation
of combining with the next one, precede the next one with two spaces
when they're being combined. Keeps nethack's message window <mx,my>
coordinates in sync with curses' internal coordinates.
Back in February, my e991dd1b0c added
ESC (when there's no input) as an early return for curses' getline,
but it neglected to clean up some allocated memory.
Fix a problem introduced by f218e3f15e
and/or a19e64e470. Sometimes the line
after a prompt would be empty and the next message get shown on the
line after that. a19e64e470 was intended to fix the opposite problem
so probably overshot the mark....
Sometimes curses tears down and recreates all its windows (when the
display is resized, for instance) and after doing that it repopulates
the message window with data saved for use by ^P. But it was showing
the oldest messages available rather than the most recent ones.
There is still room for improvement. That process combines short
messages but the refresh is based on the available number of lines;
combining messages can result in lines at the bottom of the message
window being left blank. This could be fixed by reverse-scrolling the
window and inserting more messages at the top, or by combining short
messages in history data instead of at refresh time. The second seems
easier but won't handle changing the message window's width sensibly,
and neither method handles wrapped, long lines well. A More>> prompt
(possibly more than one) is issued if the refresh shows too many lines
(either because long messages already took multiple lines or because
the window has become narrower and ones which used to fit now need to
be wrapped).
Some prompts were being overwritten by the message that followed.
And clear_nhwindow(WIN_MESSAGE) gets called for just about every
keystroke so try to reduce the overhead I unwittingly added. The
"scroll up one line earlier than the next message" mentioned in
the prior commit is much more obvious that I realized and prompt
erasure might need to be redone.
Autodescribe feedback and multi-digit count prompts are always shown
on the last line of the message window and are suppressed from message
history (both ^P and DUMPLOG). When the message window is using all
available lines, the last one was being overwritten (until the count
or the feedback was completed or dismissed, then last line returned).
Adopt the suggestion that it be scrolled up a line instead of being
overwritten. [I haven't been able to reproduce the reported problem
where shorter overlaid text left some of longer underlying text visible
but that should now become moot.]
Bonus fix: while testing, I noticed that if your screen only has room
for a one-line message window and you used ESC to cancel 'pick a spot
with cursor' prompting before moving the cursor, the prompt was left
intact on the message line. tty erases it in that situation, but the
clear_nhwindow(WIN_MESSAGE) was a no-op for curses because it usually
doesn't erase old messages. This changes the curses behavior when the
core asks it to erase the message window: now it forces one blank line
of fake autodesribe feedback (causing the prompt or other most recent
message to scroll off top), then removes that fake feedback (leaving
a blank message line). For multi-line message window, the old messages
scroll up by one line sooner than they would when waiting for the next
real message but are otherwise unaffected.
The curses interface would assign menu selector characters a-z, A-Z,
and then 0-9, but trying to type 0-9 would start a count rather than
select an entry, and if the display was tall enough for more than 62
entries, the ones after '9' were ASCII punctuation characters.
Limit the number of entries per page to 52 + number_of_'$'_entries
(which should be 0 or 1) so that it won't run out of normal letters.
The perm_invent window, if enabled, ought to allow more than that
because it isn't used to make selections and might have an arbtirary
number of '#' overflow entries. But I'll leave that for somebody
else to tackle.
Tested by temporarily setting the limit to 26 instead of 52 since
I'm not able to display anything tall enough to exercise the latter.
DEC C in one of its non-ANSI modes didn't like
fieldorder = test ? &array1 : &array2;
It first complained that '&' applied to an array has no effect (which
was typically true in pre-ANSI environments) and once those '&'s are
ignored, the attempted assignment didn't match the variable's type.
That code was actually more complicated that it needed to be; slightly
simpler code works as intended.
The curses interface wouldn't build with HILITE_STATUS disabled. I
started adapting it to handle genl_status_update() but that was taking
too much effort with each niggling detail leading to another. This
goes the opposite direction: forcing the old STATUS_VIA_WINDOWPORT
behavior without having that #define available. That dragged along a
bunch of unexpected changes too.
I've noticed many instances of the game pausing and not being sure why,
then pressing <space> and having it resume. The curses interface had
a tendency to put its equivalent of the --More-- prompt, >>, somewhere
where that wasn't visible, either off the right hand edge (possibly) or
underneath the window borders if those were enabled. Especially the
very last one it issues prior to exit. (An extra one compared to tty
behavior.)
This ended up being a pretty substantial overhaul of message window
handling. I wouldn't be surprised if it has off-by-one errors which
happen to be paired up and cancel each other out. ">>" is still drawn
in orange if guicolor is on, now in inverse video when that is off.
If it happens to be drawn at the same screen location in consecutive
instances, the first ">" will toggle between blink and not blink so
that there'll be no doubt as to whether the keypress registered when
dismissing it (moot if the text preceding it is different but there's
no attempt to be smart enough to check that, just screen placement).
Make the same fix to curses that was done for tty in 3.6.1: don't
let MSGTYPE entries be matched against prompt strings. Like tty,
curses was using ordinary pline() to issue prompts; something like
MSGTYPE=hide"yn"
could wreak havoc. Switch to custompline(OVERRIDE_MSGTYPE,...).
This changes the recently added msg_window:f for curses to start
viewing the old messages on the last page rather than the first. For
msg_window:Reversed (the default for curses) and for either direction
when all of the message history happens to fit on one page, there's
no change. But for multiple pages, the FIFO feedback now pads the top
of the first page with blank lines so that the last page is full, and
it starts out showing that last page first. So if you only want to go
back few or several messages, they will be in view immediately.
Old layout:
|first message (oldest) | |1st message of last page |
|2nd message of 1st page | | ... |
| ... | |final (most recent) mesg |
| ... | | (blank filler) |
|last message of 1st page | | (blank filler) |
| (1 of 2) => | | <= (2 of 2) |
and ^P started with first page visible and needed normal menu handling,
<space> or '>' or '|', to go forward to view the most recent messages.
New layout:
|1st message of last page | | (blank filler) |
|2nd message of last page | | (blank filler) |
| ... | |first message (oldest) |
| ... | | ... |
|final (most recent) | |last message of 1st page |
| <= (2 of 2) | | (1 of 2) => |
and ^P starts on last page (two of two in this example) but can go
back with '<' and '^'.
So if the total size takes one and third pages (which isn't uncommon
for the default number of kept messages), you'll see 3/4 of the most
recent messages on the initial screen, then you can page backward if
you want to see the other 1/4.
The page indicator is deliberately drawn a bit differently just to
draw attention to the fact you're starting on the last page. I'm not
sure whether that is actually worthwhile but it was trivial to do.
The curses interface was using 'moves' as if it meant "moves" rather
than "turns". Typing ESC at >> (curses' terser version of --More--)
prompt would suppress messages for the rest of the current turn rather
than just the rest of the current move. So if the hero got an extra
move due to being Fast, there would be no feedback during that move.
window.doc states that the colormasks argument to status_update() is
only relevant for BL_CONDITION, but curses was relying on it to be
passed for BL_FLUSH as well. Yesterday's changes stopped the latter
and broke highlighting of status conditions. Other interfaces appear
to honor the description in window.doc.
Have the curses interface save and restore message history for use
by ^P. It doesn't spit the saved messages out into the visible
message window after restore; that's too distracting.
The curses interface maintains message history in a doubly linked list
with a capacity limit. Once capacity is reached, the list head is
advanced and the old head discarded, but it was leaving the new head's
'previous element' link pointing at that discarded element.
tmp_mesg = first_mesg->next_mesg;
(at this stage, tmp_mesg->prev_mesg points at first_mesg),
free(first_mesg);
first_mesg = tmp_mesg;
(with necessary 'first_mesg->prev_msg = NULL' missing). The situation
wasn't a significant problem because traversing the list was limited
by a counter. Going from tail back to head exhausted the counter
without ever accessing the stale pointer.
Since it wasn't noticeable, I haven't added a fixes entry for this.
I've also changed it to do fewer memory allocations and frees by
reusing the old list head instead of always allocating a new element
and freeing the one being replaced.
The unresolved "first problem" mentioned earlier in commit
382286cb99 was caused by stale values
in status fields which had become disabled. Polymorphing left an
old BL_XP value and returning to original form left an old BL_HD one.
They weren't displayed but the stale value was included in the line
length calculation, resulting in 4 or 5 columns being set aside for
a phantom value. That implicitly reduced the available length of the
line and could result in extra spaces separating other fields being
squeezed out while unused spaces remained at the end of the line.
Experience points, time, and score didn't trigger this problem because
they were being explicitly excluded if disabled. So stale values for
them when they had been enabled then later disabled didn't matter.
I noticed a couple of things wrong--that I was fairly sure that I
had working correctly before--and after fixing the second one, the
first has mysteriously disappeared.
First problem, which may or may not still be a problem: extra spaces
were being removed from the second line of 2-line status even though
there were still 4 or 5 available spaces to the right of the status
conditions. It was behaving as if it thought the line was narrower
than actual size, or conversely, that the sum of the widths of the
fields plus the extra spaces was bigger than it actually was.
Second problem, fixed here. The code to put '+' in the far right
column of the last status line when there is at least one condition
all the way off the display wasn't working right when windowborders
were displayed. That's down to curses wrapping to the next line but
user can't see it due to the window border overwriting. Single char
overflow stayed on same line, but two or more wrapped and then the
'x' coordinate didn't match tests for 'too wide'. Perform explicit
truncation instead of leaving that up to curses. Also truncate
encumbrance when warranted since it's feasible for it to overflow.
Anyone using a display narrower than 80 columns might still run
into odd status behavior because other fields than conditions and
encumbrance could go past the end of line. But they shouldn't be
wasting screen real estate with windowborders, and without borders,
curses will keep the cursor in the bottom right corner when the
program tries to go past, which should keep things reasonably sane.
curses uses 'reversed' (LIFO) style when displaying previous messages.
Use the existing (previously tty-only) 'msg_window' option to also
support 'full' (FIFO). The actual code needed as just a couple of
lines; tweaking options parsing and the documentation was more work.
Using ^P right after resize or 'O' of align_message, align_status,
statuslines, or windowborders would result in
'curses_display_nhmenu: attempt to display empty menu'
because some memory cleanup I added several weeks back was being
executed when the curses interface tore down and recreated its
internal windows.
This fixes ^P handling by making sure that that menu (which is just
text but uses a menu to support '>'/'<'/'^'/'|' scrolling) will never
be empty and it also fixes the window deletion to not throw away
message history until it's final deletion at exit time.
^P uses a popup window to display previous messages and it was never
deleting that window, just creating a new one each time. Same with
the routine which displays an external help file. Using either or
combination of both close to 5000 times would probably make internal
window creation get stuck in an infinite loop. Delete those windows
after they're used so it'll never be put to the test.
The memory cleanup I added for map/status/messages/invent was only
being preformed at end of game, not when saving. Fix that too.
