TerminalInput::HandleKey should never return "unhandled" for a key event #16509
Labels
Area-VT
Virtual Terminal sequence support
Help Wanted
We encourage anyone to jump in on these.
In-PR
This issue has a related PR
Issue-Feature
Complex enough to require an in depth planning process and actual budgeted, scheduled work.
Needs-Tag-Fix
Doesn't match tag requirements
Product-Conhost
For issues in the Console codebase
Description of the new feature/enhancement
If I've enabled VT input mode, I expect to get back a simple stream of characters representing the VT sequences for each key press. If using
ReadConsoleInput
, then I'd expect a single key event for each character in the sequence, with no virtual key code, and with the character values in theUnicodeChar
field.However, what I get now is a weird mix of the original keyboard events, interspersed with the VT sequence characters. For example, if I press Ctrl+A, I expect to get a single event like this:
But what I actually get is this:
If I enter a character consisting of a surrogate pair, e.g. entering 😛 from the Win+. emoji picker, I get both up and down events for the two surrogate pairs, but the up event arrives before the down event for the first code point!
And note that I also get the up event for the . key from triggering the emoji picker. All I expected to see were the two down events representing the emoji glyph:
This all stems from the fact that we return an "unhandled" state from the
TerminalInput::HandleKey
method for key-up events, as well as key-down events that don't map to a VT sequence, and those events then get injected back into the input queue. I think it would be better if we just returned an empty string for those cases. That way the only key events that end up in the queue are the actual VT characters.Proposed technical implementation details (optional)
As explained above, we should only return
MakeUnhandled()
if we receive something that isn't aKEY_EVENT
. Otherwise we should return a blank string, i.e.MakeOutput({})
, for any key events that aren't handled.The text was updated successfully, but these errors were encountered: