The previous curses escape sequence conversion for 8-bit sequences was
looking for those to start with M-O when the correct value for that is
actually M-^O.
Add support for the number pad's non-digit keys. Most useful for real
VTxxx keyboard since emulators are usually stuck mapping '+' and '.'
to ',', '.', and '-'. There's no universal solution for that.
This attempts to address the issue on hardfought (as described by K2
on reddit two weeks ago) which happened after updating their terminfo
database. It's based on the reported workaround of having users force
their terminals to avoid "application keypad mode". The fixes entry is
my guess at what is happening so could be wrong....
I don't have a numeric keypad so this is untested; it /ought to work/.
NetHack's curses interface is doing it's own keypad recognition when
the curses library returns a multi-char sequence rather than converting
that into corresponding KEY_xxx token. Numpad keys that the interface
recognizes begin with 2 char 'ESC O' when transmitted as 7-bit sequences.
This adds support for SS3 (as sent by DEC Vtxxx terminals and emulators;
value is single char 'M-O') for 8-bit sequences.
It shouldn't break typing Alt+O but that's something else that I can't
test properly. Setting nethack's 'altmeta' option and manually typing
2 char 'ESC O' still works as intended.
This is curses-specific; the tty interface is completely unaffected.
[However, the vms port has supported SS3 with tty for decades. :-]
There was an error:
../win/Qt/qt_main.cpp:767:37: error: attempt to use a deleted function
action->setData(actchar);
^
/usr/include/x86_64-linux-gnu/qt6/QtCore/qvariant.h:199:5: note: 'QVariant<char *, false>' has been explicitly marked deleted here
QVariant(T) = delete;
^
1 error generated.
I'm hoping the fix applied is the correct one for the error.
A printf call was introduced in 20fb008012 that caused the terminal
window to be filled with repeated debugging messages as the window
containing the Qt windowport was resized. I removed it because I
assumed it was meant to be temporary and was left in the commit by
mistake, considering it isn't mentioned in the commit message; if it was
meant to be permanent it'd probably be good to block it out with #ifdef
DEBUG or something at least, because it produces a real deluge of
terminal output if the player spends any time resizing the window by
hand.
We received a report from someone whose build was failing because
of the use of cchar_t and setcchar(). They were getting errors
even though they were using an up-to-date curses library.
Apparently, ncurses requires that _XOPEN_SOURCE_EXTENDED must be
defined before the curses header files in order for those features
to be available.
We had already updated our .370 series of hints and hints/include
files with
-D_XOPEN_SOURCE_EXTENDED=1
but this person must have been building in some other way.
Instead of failing to build in that situation, allow the
fallback to the older, less-functional genl_putmixed() function,
but also try not to do so silently and display a message that
functionality is reduced.
The difference between the use of genl_putmixed() and
curses_putmixed() or tty_putmixed(), is that when doing
'/' farlook operations, curses_putmixed() and tty_putmixed() try to
display a character in the message window that looks exactly the same
as the one on the map, even if a symbol from a symset is being used
on the map, or when using ENHANCED_SYMBOLS.
Related note: curses_putmixed() matches the symbol and the color,
whereas tty_putmixed() (at present) does not attempt to match the
color.
In file included from ../win/curses/cursmisc.c:6:
../win/curses/cursmisc.c: In function 'curses_convert_attr':
../lib/pdcursesmod/curses.h:562:32: warning: overflow in conversion from 'long long unsigned int' to 'int' changes value from '2147483648' to '-2147483648' [-Woverflow]
562 | #define PDC_ATTRIBUTE_BIT( N) ((chtype)1 << (N))
| ^
../lib/pdcursesmod/curses.h:574:27: note: in expansion of macro 'PDC_ATTRIBUTE_BIT'
574 | # define A_DIM PDC_ATTRIBUTE_BIT( PDC_CHARTEXT_BITS + 10)
| ^~~~~~~~~~~~~~~~~
../win/curses/cursmisc.c:752:23: note: in expansion of macro 'A_DIM'
752 | curses_attr = A_DIM;
| ^~~~~
The curses interface was using genl_putmixed() which doesn't
preserve the symbol actually used for a glyph on the display.
This is a first-attempt at implementing curses_putmixed().
On Linux you'll need to distribute the Makefiles again
sh sys/unix/setup.sh sys/unix/hints/linux.370
On macOS, you'll need to distribute the Makefiles again
sh sys/unix/setup.sh sys/unix/hints/macOS.370
* qt_tilewidth and qt_tileheight are allocated with alloc() and need
to be freed with free().
* Don't use them after they're freed. Instead, retrieve the size from
the glyphs object.
Entering a multi-digit count when selecting from a menu in the curses
interface causes the menu to disappear. Report was about putting a
large subset of an object stack into a container but the bug affected
all menus that accepted counts.
curses_get_count() was changed to call core's get_count() quite a
while back. get_count() calls mark_synch() when more that one digit
is typed or when backspace to remove the first digit occurs.
curses_mark_synch() had been a no-op but more recently it was changed
to try to make sure that the screen was up to date. But it did that
by refreshing the persistent windows, making any temporary popup menu
or text window become hidden. Also, the count-in-progress is being
sent to the message window with the no-history flag, so refreshing
the message window removed that too.
Switch curses_mark_synch() to use the basic screen refresh call that
doesn't do anything window-specific. This also changes menu count
handling to have get_count() echo the number starting with the first
digit instead of waiting until the second.
If anything in the menu makes it be very wide it can cover up the
message window and any count being echoed there won't be visible.
I'm not going to try to figure out how to deal with that; it isn't
all that different from the old single-digit/unseen-count behavior.
Issue #1042 states the following:
> Steps to reproduce:
> *name pet so that first (or only) character is non-ascii: example Ä or emoji.
> Most of the time the name is correctly shown.
> If new row starts with pet's name then character is not printed correctly.
The kludge for handling mixed glyphs and text shouldn't have been engaging
the special handling of the first character for anything outside of putmixed().
This should resolve that.
author Ray Chason <ray.chason@protonmail.com> 1684372172 -0400
committer nhmall <nhmall@nethack.org> 1685414340 -0400
Add configuration to support Curses on WinGUI
and enable support for Unicode on Curses.
Allow NetHackW to select the Curses interface
Reorder drawing of extended command prompt
Curses on WinGUI needs this change. This may be a bug in PDCursesMod,
but it seems to be harmless to the other ports.
Avoid calling Curses after the windows are closed
Provide erase_char and kill_char for WinGUI Curses
Set Lua version to 5.4.6
Discussed a long time ago, change helm of brilliance from iron to
crystal so that it doesn't need to be a special case for metallic
armor's affect on spell casting. It now has a fixed description of
"crystal helmet" but is not pre-discovered.
Add new helm of caution to retain the "etched helmet" description
among the shuffled helms. Wearing it confers the Warning attribute.
That's fairly lame but not necessarily useless. It's iron and gets
half the former probability for a random piece of armor being helm
of brilliance so is not likely to be popular.
Helm of caution keeps the old helm of brilliance tile and new helm
of brilliance is basically the same image with different color and
pointed on the top.
Not changed: the etched helmet was marked as green and is drawn
that way for text but the tile doesn't actually use green for it.
Crystal helmet started as hi_glass (rendered as 'bright cyan') but
has been changed to clr_white to match crystal plate mail.
Old save and bones files are invalidated.
Funnel all potential "<action> called before we know if Menu or Text"
warnings through a common routine. Aside from rephrasing a message
which no one should ever see, there's no change in behavior.
Neither X11 nor Qt would compile with TEXTCOLOR disabled. With this
they build and seem to work, but no promises, particularly for the
ENHANCED_SYMBOLS config.
Noticed when working on the add_menu() crash earlier, using a mouse
rather than the keyboard to pick an entry in the sub-sub menus for
'm O' -> 'disclose' -> {any disclosure category} didn't work properly.
The problem was in post-3.6.x menu code for the Qt interface.
I temporarily reverted the fix for end-of-game disclosure of overview
in order to trigger the add_menu() crash under Qt. It came down to
if (!actual) impossible("AddMenu called before we know if Menu or Text");
actual->AddMenu(glyph,identifier,ch,gch,attr,str,itemflags);
where 'actual' happens to be Null. impossible() gets called, goes
through pline() calling putmesg() and putstr(WIN_MESSAGE), then the
output never shows up anywhere. I haven't figured our what's going
on with that, but changing the above to
if (!actual)
impossible("AddMenu called before we know if Menu or Text");
else
actual->AddMenu(glyph, identifier, ch, gch, attr, str, itemflags);
at least prevents the crash. The main window ends up becoming
minimized/iconified but the final popups which occur after disclosure
appear and accept responses and then a clean exit takes place.
Presumably it used panic() rather than impossible() at some point,
otherwise that code makes no sense: test for Null then deference it
regardless of the result of the test?
to program_state.input_state
Rename program_state.getting_a_command and give it an int value
instead of treating it as boolean. Start using to it for Qt to
suppress commands initiated from the drop down menus in the title bar
if nethack isn't expecting to get a command from the user. Those menu
choices inject extended command text into the input stream and should
be avoided when entering text or waiting for a menu to be dismissed.
These menus would be better if they grayed out unavailable choices
when pulled down instead of accepting any choice and then treating
that no good. I'm not going to try to figure out to do that with Qt.
And this workaround for the menus doesn't have any affect on the
toolbar buttons below the title bar. Those execute core commands
directly and when I tried to use jacket routines instead, the tool bar
stopped showing up so I've given up.
This won't fix the reported problem of getting stuck in a loop.
My guess about NCURSES_CONST was right; it expands to nothing in the
/usr/include/term.h on my old OSX system. There aren't any levers or
knobs available to avoid that so this adds casts of string literals
to avoid warnings about passing a literal to something that expects
non-const.
There's a lot of conditional code in termcap.c and the nhStr("foo")
(hidden cast) changes only got tested for my default configuraiton.
I tried to avoid typos but I attempt such all the time and we know
how that tends to go.
Are we sure that systems which need to install a curses development
package have term.h without that? A tty-only build shouldn't require
that.
In curses, selecting a partial stack, then unselecting the entry,
and then selecting it normally, the entry still kept the quantity
from the partial selection. Make it behave like all the other
windowports by resetting the quantity when the entry is unselected.
- Move secondary preprocessor defines down further in config.h
so that they can be overridden via [platform]conf.h which is
included from global.h, specifically:
LIVELOGFILE when LIVELOG is defined
DUMPLOG_FILE when DUMPLOG is defined
- Minimize platform-specific, or compiler-specific code in hack.h and decl.h.
- reorganize src/decl.c to align with include/decl.h.
- a new header file cstd.h added, containing calls to C99
standard header files.
- hack.h, decl.h, and decl.c have been cleaned up and had code
moved so that things line up as follows:
hack.h defines values that are available to all
NetHack source files, contains enums for use in all
NetHack source files, and contains a number of
struct definitions for use in all NetHack source files.
It does not contain variable declarations or variable
definitions.
decl.h contains the extern declarations for variables that
are defined in decl.c. These variables are global and
available to all NetHack source files. The location of
the variables within decl.h was random, so give it some
order for now.
decl.c contains the definition of the variables declared in
decl.h, and initializes them where appropriate. The
variable definitions are laid out in much the
same order as their declarations in decl.h.
- wintty.h: There were some varying terminal-related prototypes in
system.h, and that was the only thing left that demanded that
system.h be included. Those have been replaced by an #include
<term.h> in include/wintty.h to get the more current (and hopefully
more correct) prototypes, rather than hardcoding them in NetHack
sources.
For edge-case platform compatiblity, there is no #include <term.h>
if the build defines NO_TERMCAP_HEADERS. In that case one set of
hardcoded prototypes is still used in include/wintty.h.
The added #include "term.h" is also bypassed for NO_TERMS builds (builds
that don't link to terminfo/termcap at all, but still present a tty
interface using platform or window-port specific functions to fulfill
the same role as that of terminfo/termcap).
- some scattered, unnecessary #include "integer.h" were removed from
various files, since that's always included in current NetHack-3.7
sources, either directly from config.h or indirectly from #include
"hack.h".
- system.h references removed.
- new cstd.h added; the #include "system.h" references in Makefiles
and project files (Xcode, visual studio), were replaced
with #include "cstd.h" references. A "make depends" is probably
warranted.
Also:
- Use of <term.h>, which defines clear_screen() as a macro, conflicts
with an actual function with that name in win/tty/termcap.c. The most
straight-forward course of action was to rename the NetHack function,
and change the references to it, from clear_screen() to
term_clear_screen(), so that was done.
This is a better workaround for the missing message window border when
when restoring with align_status:left. Unlike the previous hack, this
may even be the correct way to handle it in the first place.
I haven't tracked down when the problem started.
This fixes the missing message window border when restoring with
align_status:left (which narrows and forces that window to the right).
It can't possibly be the correct way to fix things but does work.
This was not a problem with 3.6.4 (the most recent pre-3.7 playground
I have on hand) but I don't have the energy to use 'git bisect' to
track done when it started to whether the cause is discernable. The
message history is put into place without going through putstr() so
differs from normal message handling.
Dynamically resizing the terminal window during play by dragging its
edges was beeping (a lot if you dragged slowly). Recogize the key
code sent for that instead of complaining about unrecognized input.
Reported by jeremyhetzler: with recently revised curses interface,
when dismissing a menu or prompt with ESC the screen flashed.
This was caused by calling beep() when the terminal is set for
'visible bell' (of flagged as incapable of 'audible bell'); the
curses library flashed the screen deliberately. We don't want that.
Change the function key handling to not call beep() when an ESC
is typed by itself rather than being the leading part of a
multi-character escape sequence. beep() will still be called if
you type an arrow key (or other function key) when nethack is
expecting text input. That's what the recent change intended.
This also removes an early return from parse_escape_sequence()
when a number pad key generates an escape sequence. I don't have
a number pad to verify that this bit works as intended.
Closes#1002
remove a couple of extraneous files from visual studio project
remove several trailing whitespace at end of line
remove an address sanitizer bounds error during player dialog init
rework fix for darkened lit tiles (fix issue #997)
While watching a ttyrec, I noticed strange behaviour in
the cursor updates; it was moved to approximately middle
of the map window every so often, usually when doing ranged
attacks. This wasn't really noticeable in normal gameplay,
as it was moving the cursor there, and then almost immediately
to where it was supposed to be.
I managed to trace it down to the refresh() in curses_delay_output().
That call updates the terminal to match the ncurses stdscr window,
but the stdscr window cursor position wasn't updated by NetHack.
Some bits made when attempting and failing to figure out the curses
problem (which turned out to be an early return skipping reset of
input timeout and fixed by paxed).
parse_escape_sequence changed getch timeout, but when receiving
a certain escape sequence, it returned without changing the
timeout back. This caused all subsequent getch calls be
non-blocking, and getch returns ERR when there's no input
waiting in that mode.
NetHack interprets ERR as the terminal going away, so performs
an automatic save.
