RE: unget_wch() seems to fail for non-print keys on Linux systems

[pjfarley3]

> -----Original Message-----
> From: Thomas Dickey <dickey@his.com>
> Sent: Saturday, May 15, 2021 6:34 PM
> To: pjfarley3@earthlink.net
> Cc: bug-ncurses@gnu.org
> Subject: Re: unget_wch() seems to fail for non-print keys on Linux systems

First, thank you for the prompt and thorough reply.  Appreciated.
 
<Snipped> 
> hmm - pdcurses might handle this by more bits, but I don't see it in the
source.
> The source only passes a wchar_t around (there are no extra bits).
> 
> More likely, if your script is showing it returning KEY_CODE_YES after
doing
> unget_wch and wget_wch, it has the KEY_CODE_YES from the previous
> wget_wch/wgetch call, and happens to be using it (incorrectly).

The python get_wch() function only returns curses.ERR on failure or a key /
keycode value on success, so it isn't possible to check for KEY_CODE_YES per
se, but testing the python type of the returned value will distinguish
between the two cases other than ERR.

<Snipped> 
> The script appears to be working as designed...

Thanks for the confirmation.

> The basic problem is that unget_wch cannot tell if a code is intended to
be a
> special key.  It only handles wide characters.  If you do an unget_wch for
> KEY_LEFT, it will be treated as the wide character which has that value,
and the
> next call to get_wch will say it is a wide-character (not a special key).
> 
> That problem doesn't happen with getch/ungetch, because there's only one
> value to consider (the character-or-keycode, which is detected by the
different
> ranges: characters are 0..255, while keycodes are past 255).
> 
> You can call either function in ncurses because unget_wch handles wide
> characters by converting them to multibyte strings.  ungetch doesn't do
that, so
> it is always possible to tell if the values that it puts into the fifo are
characters or
> keycodes.
> 
> > If someone on this list would be kind enough to run this example code
> > on their own linux system to see the issue I am reporting, and then
> > tell me whether I should be looking to the python development team for
> > a solution or if this is possibly a bug in the underlying ncurses
> > code, I would very much appreciate it.
> 
> It's not a bug in ncurses.  It might be a useful extension (with a
different function
> name) to have a wide-character unget which knows about keycodes, But it's
not
> essential because ungetch can always be used for keycodes.

Then if I understand correctly, if get_wch() returns KEY_CODE_YES (or in the
python version, if the return value is of type integer rather than type
string) then I should be able to use ungetch() with the integer value
returned from get_wch() to put the key code back for the next get_wch() to
retrieve, is that correct?

One ancillary question: What is the actual difference between the keyname()
and key_name() functions?  I have read the description in the man pages
several times and still don't quite understand the difference.

Peter