bug-ncurses
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Dickey
Subject: Re: unget_wch() seems to fail for non-print keys on Linux systems
Date: Sat, 15 May 2021 18:33:51 -0400
User-agent: Mutt/1.10.1 (2018-07-13)

On Fri, May 14, 2021 at 01:24:54AM -0400, pjfarley3@earthlink.net wrote:
> Hello,
> 
> I work in python using curses libraries in both linux environments and in
> Windows environments but I don't yet know whether this is a python issue or
> an ncurses issue in linux environments, so I am asking here for your help
> and advice.
> 
> I am hoping you can help me narrow down where this bug may be happening by
> telling me if the behavior I see with python is normal for ncurses on linux
> or not.
> 
> I have attached a fairly simple python script that uses ncurses on linux
> systems and PDCurses on Windows systems.  On Windows systems this code
> *always* operates correctly.  On Linux systems (tested on Ubuntu 20.04 LTS

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

> and Debian 10) using recent ncurses versions (6.2 on Ubuntu, 6.1 on Debian)
> using the python syntax "stdscr.unget_wch(keyvalue)" where "keyvalue" is not
> a printable character (e.g., End, Home, arrow keys, function keys etc.) it
> seems to fail to correctly put the entire keycode back into the input buffer
> such that a subsequent "stdscr.getkey()" fails to either retrieve the actual
> keycode value or to translate it correctly to a "KEY_*" name.
> 
> Operating the example program "pycurses4.py":
> 
> 1. If it isn't already installed in your linux system, install whichever
> python3 version your distro supports.  On Ubuntu this is currently 3.8.5, on
> Debian 3.7.3.
> 2. In a terminal window, run the command "python3 pycurses4.py"
> 3. When the program presents you with its screen, type the letters "a", "b"
> and "c to observe what they do to the screen contents
> 4. Next press the up, down, left, right arrow keys and observe the
> difference:
>       a. The "get_wch()" and "getkey()" results (on screen, the "Last wide
> character pressed:" and "Last 'key' value pressed:" lines, respectively)
> will be correct values for both the letter and arrow keys
>       b. The "getkey()" results will be incorrect for the arrow keys
> because the "unget_wch()" following the "get_wch()" for the arrow keycodes
> fails to allow "getkey()" to retrieve the same key value or perhaps fails to
> allow it to translate the retrieved value to the correct keycode name
> 5. Quit the program by typing the "q" key (only lower case "q" quits the
> program).
> 
> To prove that the code does perform "getkey()" correctly, run the program
> again with "python3 pycurses4.py ck" which will run only the "getch()" and
> "getkey()" parts of the program.  When the "get_wch()" part is not executed,
> only "ungetch()" puts the received keycode back into the input buffer, and
> "getkey()" is then able to retrieve and return the name of that that keycode
> correctly.

The script appears to be working as designed...

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.

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

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]