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

[Thomas Dickey]

On Sat, May 15, 2021 at 08:51:32PM -0400, pjfarley3@earthlink.net wrote:
> > -----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?

that sounds right
 
> 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.

key_name is part of the wide-character binding, and expects parameters
which may be larger than 8 bits:

       char *keyname(int c);
       char *key_name(wchar_t w);

keyname expects an 8-bit value, and relies upon a built-in table.

https://pubs.opengroup.org/onlinepubs/7908799/xcurses/key_name.html

goes into some detail about keyname, but (reading it closely) has
nothing to say about the return-value of key_name except perhaps
the control characters ^C, etc.  The meta and KEY_xxx don't apply.

ncurses returns a "^C" for 3 (control/C) and the UTF-8 equivalents for the
other characters.  It hadn't occurred to me, but I could make it closer
to the X/Open wording by returning "UNKNOWN KEY" for zero-width characters.
That doesn't seem like an improvement, though.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
https://invisible-island.net
ftp://ftp.invisible-island.net

signature.asc
Description: PGP signature