Implement $Host.UI.RawUI.ReadKey()

[noopman]

Implement $Host.UI.RawUI.ReadKey() to read one key from the keyboard.

Today Read-Host makes you press two keys.

[Console]::ReadKey() is a workaround, but which is the "proper" way to read a key input from the user?

[Halkcyon]

With improvements to the terminal in the June 18 release of VSCode and talks about dropping older version support, I think they may have been holding back the integrated terminal and this would be fixed over time automatically.

[TylerLeonhardt]

@TheIncorrigible1 not quite. The VSCode extension uses a custom host in the PowerShell Integrated Console and that's something we maintain. It's not as feature-rich as powershell.exe's host.

So this is on us to implement and we haven't gotten to it.

@SeeminglyScience also mentioned that replicating the exact functionality will be difficult because $Host.UI.RawUI.ReadKey() provides details on key up and key down actions.

[TylerLeonhardt]

P.S. Thanks for commenting on a few issues :) appreciate that 👍

[SeeminglyScience]

Hmm, in VSCode I'm not sure that it will be possible to get the same behavior at all. Out of curiosity I pulled the $Host from the start up runspace (which would still be the default ConsoleHost).

When holding down a key conhost acts differently than xterm. Doing something like this:

while ($true) {
    $Host.UI.RawUI.ReadKey('IncludeKeyUp, IncludeKeyDown')
}

If you hold down a key while the above is running, conhost will report only key down until you release the key. xterm.js on the other hand will return both a key down and key up for every repeated character. I'm guessing this is a limitation of node-pty.

Side note: We should probably save the $Host variable from the initial runspace somewhere during start up. If there's a host feature that we don't need a custom implementation for we could just call ConsoleHost, at least as a sort of stop gap. Not sure why I never thought about that.

We could even use that to implement this method, though I doubt it would obey pipeline stop requests.

[TylerLeonhardt]

Hey @Tyriar sorry to bring you into this. I was wondering if you have any context to what @SeeminglyScience was saying.

[Tyriar]

The issue is you don't get individual keyup and keydown events? VT doesn't communicate keyup/keydown events, just key events. This may be something lost in translation going from the verbose Windows Console API to VT.

[TylerLeonhardt]

Thanks @Tyriar!

@SeeminglyScience, I think we probably need to bring this up in the PowerShell repo so we have a consistent story across OS's and terminals.

I wonder if it's worth having the same functionality (aka key event) on all OS's and terminals - then have a flag to get legacy functionality if we're in a Windows Console API-based environment.

@SteveL-MSFT + @joeyaiello any thoughts?

[SteveL-MSFT]

Even PowerShell Core console host has this difference where on Windows, you can get the individual key up/down signals, while on non-Windows, you only get the key down. I don't think VSCode-PS needs to do anything different here.

[TylerLeonhardt]

I think we can close this now. $Host.UI.RawUI.ReadKey() is available in the PowerShell Preview extension.

As for the behavior, it's out of our power. It's really out of PowerShell's power too. It depends on the pty layer (it seems).

conhost can read key up and key down
vscode terminal can only read key down
Windows Terminal can only read key down

and really any terminal on non-Windows can only read key down.