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

[pjfarley3]

> -----Original Message-----
> From: Thomas Dickey <dickey@his.com>
> Sent: Sunday, May 16, 2021 2:20 PM
> To: pjfarley3@earthlink.net
> Cc: bug-ncurses@gnu.org; dickey@his.com
> Subject: Re: unget_wch() seems to fail for non-print keys on Linux systems
<Snipped> 
> > 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

Looks like our replies crossed in the aether 😊.  Thanks again for your insight.

> > 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.

I agree it is vague on the subject.  Thank you for the explanation of the 
difference in the functions.

> 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.

It would be only a small improvement, probably not useful enough to bother with 
though.

More useful perhaps would be integrating the more self-descriptive PDCurses key 
names for CTRL-non-print-key and ALT-non-print-key.

E.G., PDCurses returns the name "CTL_PGUP" for CTRL-PgUp and "ALT_PGUP" for 
ALT-PgUp.  On the other hand, ncurses returns key names of "kPRV5" and "kPRV3" 
for those same combinations.

One area where PDCurses differs significantly from ncurses in philosophy is 
that CTRL and ALT combinations of the numeric keypad non-printing (NumLock off) 
key names are made explicitly different, not identical to CTRL/ALT combinations 
of the separate non-printing keys.

E.G., PDCurses returns "CTL_PAD7" for Ctrl-Numeric-Pad-7 key (also named Home). 
 It will also return "PADENTER" for the numeric pad Enter key.

Philosophically of course it is the question of whether the numeric pad keys 
should or should not be distinguishable from the non-keypad equivalents.  
PDCurses chooses to make them distinguishable while ncurses does not.

I take no position on which is the more "correct" philosophy.  The ncurses 
choice makes sense due to the large range of terminals and emulators it 
supports.  The PDCurses choice perhaps makes sense if one limits oneself to 
today's ubiquitous emulators based on "standard" PC keyboards, ignoring real 
terminals, but I can see that even that reasoning could be argued against given 
the differences in emulators across various system implementations.

Leaving aside the philosophical difference, IMHO it would be a nice-to-have 
ncurses enhancement to have an easy-to-use option to return the "CTL_keyname" 
and "ALT_keyname" strings instead of the "kPRV5" and "kPRV3" names for both the 
separate and numeric keypad non-printing keys.

Regards,

Peter
--