Keypresses outside of readchar_linux() are dropped

Chars that are pressed while outside of readchar will be dropped. I presume this is because readchar enters raw mode right before calling read, but returns to cooked mode thereafter.

This means that if you press keys faster than you do your processing keys will get dropped. This manifests as characters showing on your display (as part of the line-editing mode of your tty) but not being captured by readchar.

To reproduce:

from readchar import readchar                                                                                           
from time import sleep                                                                                                     
from sys import stdout                                                                                                     
                                                                                                                        
captured = ""                                                                                                           
                                                                                                                        
for i in range(10):                                                                                                     
    c = readchar()                                                                                                      
    captured += c                                                                                                       
    stdout.write(c)                                                                                                     
    stdout.flush()                                                                                                      
    sleep(0.1)  # placeholder for "very slow processing"                                                                
                                                                                                                        
print("\nactually captured", captured) 

Run this, and mash the keyboard for approximately 1 second.

I originally presumed the cause of the problem is that readchar enters raw mode right before calling read, but returns to cooked mode thereafter. However, commenting out the return-to-cooked-mode part of the code does get rid of echoing of uncaptured characters, but does not actually capture the characters that are typed while being outside of readchar.

Original issue below (which reflects less understanding of the issue but has more context)

===

original below.

I’m using python-readchar for a small utility to practice my typing speed. When 2 characters are pressed almost simultaneously, sometimes the following happens: 1 of the 2 chars ends up on screen, but is not captured by python-readchar. This was hard to reproduce, but in the end I managed by using the simple utility script.

This reveals the following timings:

0.095735 1                   <= captured character
0.000025 1                   <= uncaptured character

As you can see, we’re in sub-milisecond territory here.

I’m not sure where to take it from here, since I’m a bit out of my depth in the functioning of tty’s etc.

Potentially relevant parts of my system:

• bash --version GNU bash, version 5.1.8(1)-release (x86_64-pc-linux-gnu)
• xfce4-terminal 0.8.10 (Xfce 4.16)
• Python 3.9.7
• readchar==3.0.4

[Cube707]

As I had to revoke my previos statement, The only soloution seems to be to note this as a limitation of the libary on linux. It will not propegate its teminal-settings outside of its own code, so it can only capture keypresses while blocking. As this works fine when running quick enough (or on a seperate thread handeling the input) this seems acceptable, even if its sad.

Maybe developing additional functionalaty for the libary in form of a context-manager would be a interesting idea. But this will be challenging to get libary ready

[petereon]

Hi @Cube707, what exactly is the intent with context manager? Looking at the code, I am not entirely sure what the approach would be. Could you elaborate?

Something that occurs to me is attaching some custom handling to “signals” to make sure terminal is reset after KeyInterrupt as demonstrated here.