Fixes#235
For initial options under curses, specifying 'DECgraphics' as a
boolean rather than as 'symset:DECgraphics' wasn't overriding the
new default 'symset:curses'. Since previously DECgraphics was
rejected for curses, it's possible that no one noticed.
Primary and rogue symbols were being set to default if primary hadn't
been given a value, possibly clobbering rogue symbols if those had
been given a value. Initialize them independenly.
Return early from curses_convert_glyph() if the value doesn't have
the 8th bit set since it now deals exclusively with DECgraphics
handling. Force a sane value for returning early on rogue level.
Move a declaration that became mid-block when a preceding 'if () {'
got removed to top of block suppress warning about C99 feature.
Add new entry for the curses symset change to fixes36.3.
This time I'm putting things in as-is before making a few tweaks.
The pull request was three or four separate changes. I used the
patch instead so they've been collected into one commit.
Highlighting for monsters shown due to extended monster detection and
for lava shown in black and white didn't work because that keys off
of 'iflags.use_inverse' (actually a macro for 'iflags.wc_inverse') and
curses wasn't enabling that window-capability option. To be fair, it
was probably unconditional at the time the curses interface was first
developed. It checked for whether a monster was supposed to be drawn
with inverse highlighting but wouldn't draw it that way because the
flag was always false. Inverse b&w lava is relatively new and curses
hadn't been taught about it.
Various other things such as pets (if hilite_pet is on) and object
piles (if hilite_pile is on) get highlighted with inverse video when
use_color is off, regardless of whether use_inverse is on or off.
That's probably a bug.
Fixes#230
Incorporate github pull request #230, support for DECgraphics-style
line drawing in the curses interface. I've rewritten the
curses_convert_glyph() part so that it doesn't require C99 and
doesn't reinitialize its pair of arrays for every character written
to the map. The DECgraphics conversion is now a straight char for
char one, DEC line drawing code to ACS, without regard to what map
symbol is intended or what 'cursesgraphics' uses for that symbol.
Have the 'menucolors' option control menu color pattern matching
(instead of curses-specific 'guicolor') for all menus, not just for
the persistent inventory window.
Commit e3af33c9db in June changed
curses handling for perm_invent to strip off doname()'s "a ", "an ",
or "the " prefix in order to shorten inventory entries and get a
couple of significant extra characters before end-of-line truncation.
That had an unintended impact on menu colors pattern matching for
patterns which expected the article prefix. Do the matching before
stripping off the prefix instead of after so that the matching gives
the same results as when used on a normal inventory menu (even though
this means that from the user's perspective most perm_invent entries
will have invisible text at the start).
Also for menu colors, don't require curses-specific 'guicolor' option
be enabled when the general, more-specific 'menucolors' option exists
to control menu coloring. (curses was requiring that both be True.)
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.
