Ctrl-C doesn't work if PowerShell was started with Russian keyboard layout

[ForNeVeR]

Environment

PS version: 7.0.0
PSReadline version: 2.0.0
os: 10.0.18362.1 (WinBuild.160101.0800)
PS file version: 7.0.0.0
HostName: ConsoleHost
BufferWidth: 170
BufferHeight: 32766

Steps to reproduce

1. Enable Russian keyboard layout on Windows (I use Alt-Shift to do that)
2. Start PowerShell Core 7.0 (which includes PSReadLine 2.0)
3. Press Ctrl-C in the shell

Expected behavior

Ctrl-C should terminate current command/input/whatever, it should work as Ctrl-C usually do.

Actual behavior

Russian letter "с" getting inserted into the command line, and no actual Ctrl-C behavior happens.

Ctrl-C is still broken even if I switch to the English keyboard layout (then English letter "c" gets inserted inctead of actual Ctrl-C behavior heppening).

[iSazonov]

@ForNeVeR Do you see the issue without PSReadline? If no please move the issue to PSReadline repo.

[ForNeVeR]

@iSazonov, no, I cannot reproduce the issue without PSReadLine.

Isn't this repository already a PSReadLine repo? I can see that some repository movement has been involved, but this is definitely a repo I have been reporting PSReadLine issues earlier.

Please direct me to a right repo if this isn't right. I've tried searching for other PSReadLine repo but wasn't successful, sorry.

[iSazonov]

Isn't this repository already a PSReadLine repo?

Oh, sorry.

[daxian-dbw]

Ctrl-C is still broken even if I switch to the English keyboard layout (then English letter "c" gets inserted inctead of actual Ctrl-C behavior heppening).

@ForNeVeR Thanks for the reporting. Just want some clarification on this behavior, was it broken for you when using the English keyboard from the very beginning?

[ForNeVeR]

Ctrl-C works fine if I start PowerShell session when English keyboard layout is active. It is only broken if I start the session with Russian layout.

[daxian-dbw]

A duplicate of this issue is reported in #1442 with a different repro -- ctrl+r results in the Russian letter к.

[ForNeVeR]

Yes, actually all of the Ctrl-hotkeys are broken.

[ForNeVeR]

Exact steps to reproduce:

1. Start PSReadline (e.g. by starting PSReadline-net461 from sources).
2. Enable Russian keyboard layout, and then press Ctrl-C or Ctrl-R one time (it won't work).
3. After that, you may change the current keyboard layout as many times as you want, Ctrl-hotkeys won't work for you in this session. The session is absolutely broken.

Also, I've been able to reproduce the issue both in PowerShell Core and in PowerShell 5.1.

I was able to determine that the culprit is likely Microsoft.PowerShell.PSKeyInfo.KeyInfoAsString: this method returns a string "Ctrl+к" even when I press Ctrl-r with English keyboard layout enabled (and the input argument properly indicates Ctrl+r as being pressed). Most likely, there're two different issues:

1. Something in PSKeyInfo is static and wrongly so, so it remembers my (Russian) keyboard layout when I enter this method for the first time, and then reuses this layout even if I change it afterwards.
2. It just doesn't work as it should: it relies on the current keyboard layout for some reason, when the expected behavior would be to ignore it and always use the default one (at least, every single program I know behaves that way with the Russian+English keyboard layouts; there may be some exceptions from this rule, but I'm not aware of them yet).

I'll try to investigate further.

[ForNeVeR]

This call of ToUnicode causes problems:

PSReadLine/PSReadLine/Keys.cs

Line 150 in 7024968

int charCount = ToUnicode(virtualKey, scanCode, state, chars, chars.Length, flags);

On my system, it looks like it remembers the first keyboard layout with which it is called, and then it just uses it for all subsequent calls. So, while it obviously should hold "r" for input values of ConsoleKey.R, 19, (an array of 256 zeros), (an array of 2 zeros), 2, 4, actually it returns a Russian letter "к".

In the documentation, it isn't specified which layout it will use, but I could try to guess it uses current thread layout or something like that, and, since this code is called on a background thread (which may not process keyboard layout change messages properly), it may actually auto-initialize the keyboard layout for the first usage, and then leave it as-is. And this behavior could be dependent on OS version, installed language pack, or whatever else factor comes into play here.

I believe we could try to load an English keyboard layout and pass it to ToUnicodeEx (which takes a layout as input instead of relying on some vague global value), since our hotkeys seem to be specified in English.

@lzybkr, am I right? Would that be a good fix for the issue? I'm not quite sure why do you call all this ToUnicode business instead of e.g. creating a table like ConsoleKey.R => "r", but it surely was a good reason, I presume?