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.
Fix:
../sys/winnt/nhraykey.c: In function 'CheckInput':
../sys/winnt/nhraykey.c:459:37: warning: type of 'mode' defaults to 'int' [-Wimplicit-int]
int __declspec(dllexport) __stdcall CheckInput(hConIn, ir, count, numpad,
^~~~~~~~~~
Twice I've gone through the curses code to deal with CHAR_P, BOOLEAN_P,
and so forth. Both times I eventually changed my mind. This time I'm
just adding an explanatory comment instead.
Extend the earlier support for Delete/Rubout in getline() to the
text entry for extended commands. In other words, treat <delete>
and <backspace> as synonyms in both places.
Some reformatting too, but only in a couple of the files.
This takes care of a lot of the leaked memory in the curses interface.
It still needs to free memory allocated for status fields when the
status window is destroyed at game end; likewise for message history
when the message window is destroyed.
There was no provision for malloc() potentially returning Null and it
wasn't integrated with nethack's MONITOR_HEAP. 'heaputil' shows that
the curses interface is leaking like a sieve. If some things are
actually being allocated separately and then freed from within curses,
those need to be thoroughly documented and maybe switched back to
malloc().
Caught by automated build test
../win/curses/cursdial.c:598:9: error: non-void function 'curses_display_nhmenu' should return a value [-Wreturn-type]
return;
^
../win/curses/cursdial.c:605:9: error: non-void function 'curses_display_nhmenu' should return a value [-Wreturn-type]
return;
