v2.0 doesn't always support arrow-key on windows

[Cube707]

the example from the readme doesn't work with v2.0 or v2.1 in windows, the arrow keys aren't working. Mostlikly because windows isn't consisten with it escape codes for special keys (both \x00 or \xe0) and you only have lookups for one of them.

[petereon]

Hey @Cube707, thanks for reporting. This is weird, I have specifically tested on Windows and it worked for me. Could you post the version of Windows and Python?

[Cube707]

This is not dependent on the python version, its a windows thing.

It depends on the terminal used and how your windows is handeling text (codepage etc..) you need to handle both versions of the special key, otherwise you will get hard to reproduc problem on some windows system.

Thats why readchar ensures it returns the code consistent to the definitions in the key module

[petereon]

So, there is also a key module in beaupy which is largely inspired by readchar aims to make a distinction between platforms. It worked for me on PowerShell on Windows. I guess, as you say, it comes down to specific console. Did you test with PowerShell or CMD or something else entirely?

[Cube707]

I am working with CMD from inside vscode. I also just tested bare-CMD and it works there...

[Cube707]

But you can test the ARROW-keys on the numpad, those don't work inside bare-CMD. (they seem to use the other code most of the times..)

[Cube707]

But like I said, I know the problem from readchar, You need to handle both version In some form or the other. They are both valid. For example, UP can be \x00H or \xe0H.

readchar handles this by allway making sure it returnes \x00 as the first char- of a longer key.

[petereon]

Ah well, I should not have kept the Windows support, should I? :sweat_smile: I'll be labeling this as a bug and looking into this, thanks for reporting again!

[Cube707]

Also sidenote: click.getchar() reads 32 bytes on posix, So You will propably get wird sideeffects if the input buffer ever holds more that a singel char. (for example if you can't process input faster that it comes in)

[Cube707]

Ah well, I should not have kept the Windows support, should I?

😆 yeah well. It took me a while to get readchar as cross-platfrom as it currentl is, and it still has issues that are not really solvable. geting single chars is just a mess in genereall...

[petereon]

Point taken. I am fairly aware migrating the whole solution towards click.getchar() was a major misstep, I just desperately wanted the ESC key and now I bear the consequences.

Lately I am eyeballing some low-level stuff that tracks pressed keys rather than trying to parse them into characters but that also seems like a completely new can of worms to open. I am frankly amazed how difficult this is in Python :smiling_face_with_tear:

[Cube707]

Same here which is why I am so involved with readchar. This seems like something that must work, but its surprisingly hard to implement.

I also thought about handling the character polling in C, but the mess actually goes down to the OS level, so there's no real benefit sadly.

I also read through the differen avaliable ways to get key-events direct, but thats a lot of setup, especially for All keys 😪. And I would like to keep the option Piping input to the program

[petereon]

Yeah, I actually went ahead and implemented a little C proof of concept for picking up characters to see whether it can be handled more sanely there and found the exact compatibility hell you mention, but in a more unwieldy language :smile: .

Some platforms accepted some key combinations, other didn't. I am yet to find one solution to handle stuff like ctrl/cmd+enter as opposed to plain enter, which I feel is a largely agreed upon way to make distinction between new line and confirm/send functionality.

[petereon]

Should be fixed by #40