gh-127947: Repeat PyREPL key events on Windows when wRepeatCount > 1

[SimonvBez]

Keys that are repeated into PyREPL were typed only once on Windows.
This has been consistently happening when typing a dead key repeatedly, such as when double-pressing the quote character on the US International keyboard layout.
This change makes those characters be typed the correct number of times.

• Issue: PyREPL does not handle wRepeatCount on Windows, causing incorrect 'dead key' behavior #127947

[ghost]

All commit authors signed the Contributor License Agreement.

[ZeroIntensity]

It's good to see new contributors :)

Could you add a test? See the devguide for how to write tests.

[SimonvBez]

There was no test coverage for the WindowsConsole.get_event method yet, because it was being mocked fully.
So I have added two tests that mock WindowsConsole._read_input (used within get_event) instead, to test if the INPUT_RECORD.Event.KeyEvent.wRepeatCount is indeed properly used.

[ZeroIntensity]

I'll review this soon-ish. Could you deal with the merge conflicts in the meantime?

[SimonvBez]

I see #128389 has caused a merge conflict. The changes there are minimal, but it isn't marked as getting backported to 3.13.
I will resolve the conflict to the current main branch. Is there anything else I should do to make backporting my changes to 3.13 easier?

[ZeroIntensity]

Nah, backporting is pretty easy even if the automation fails. Just deal with the conflicts on main and you're good.

[SimonvBez]

The one thing I'm not sure about is the current distinction between WindowsConsole.event_queue and WindowsConsole.key_repeat_queue.
The event_queue already existed and was only used for a "scroll" event (until #128389 started using it too).
But using the event_queue will put a delay of 0.01s until it will get handled, because of the wait() function.
I did not want to change the existing behavior, so I opted to create the key_repeat_queue and made the wait() return immediately if there is anything in key_repeat_queue, so that repeated keys would appear immediately instead of with a 0.01s delay.
But looking at it right now it might be better to merge the queues into just event_queue, and make it also circumvent the wait() sleep.

EDIT: I have been playing with it for a while, and there seems to be no change in behavior when allowing the event_queue to prevent wait()'s sleep. So I have removed my new key_repeat_queue and queue repeated keys into event_queue as well instead.

[SimonvBez]

I have no clue as to why one of the automated Ubuntu tests is failing of all things, considering there have only been pyrepl Windows-only changes.

[ZeroIntensity]

Hypothesis is known to be flaky right now. I've restarted the job for you, let me know if it continues to fail and I'll just rerun it until it works.

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[pablogsal]

This only repeats the returned Esc event for ALT_ACTIVE keys. Alt+a with wRepeatCount == 2 becomes Esc, a, Esc, so we lose the second a. Can we repeat the full translated sequence here?

[pablogsal]

What happens when a key with ALT_ACTIVE repeats (wRepeatCount > 1)? _event_from_keyevent already queues the real key and returns the meta \033, so this loop only duplicates the meta event and we lose the repeated key, leaving a dangling meta. We probably want to repeat the whole meta+key sequence here, no?