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

[Bill Gray]

On 5/15/21 6:33 PM, Thomas Dickey wrote:
> 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).

   That's not necessarily a barrier.  You just have to make
sure that special keys have a wchar_t value that will not
collide with a valid key code.  Some time back,  I did this
in my fork of PDCurses for other reasons :

https://github.com/Bill-Gray/PDCursesMod/blob/master/curses.h#L903

   This is based on the fact that Unicode U+E000 to U+F8FF
is a 'private use area' (PUA),  and we can be reasonably sure
that no actual key will return values in that range.  Doing
that,  you can look at the value returned from getch( ) or
wget_wch( ) and determine if it's a function key;  there is
no issue of possible overlap between regular wide characters
and function key codes.

   Somebody argued that if "our" function key codes were in
the middle of that range,  near 0xEC00,  we would be still
less likely to collide with someone's use of the PUA.  Which
is why KEY_OFFSET is defined to be 0xEC00 for wide-character
builds and 0x100 for 8-bit builds.

   I wanted to have special key codes start just outside the
range of Unicode,  at U+110000.  Unfortunately,  a certain
large company in Redmond uses 16-bit wchar_t values,  so I
had to drop that idea.

-- Bill