fix: don't rely on value from GetNumberOfConsoleInputEvents#15
Conversation
the-mikedavis
left a comment
the-mikedavis
left a comment
There was a problem hiding this comment.
Awesome, thanks for digging into this @aschey! I just have a tiny style nit
| impl Debug for InputHandle { | ||
| fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result { |
There was a problem hiding this comment.
for Debug I like to import std::fmt and then impl fmt::Debug for T { .. }, since it means we can use fmt::Formatter and fmt::Result in the signature here
aschey
force-pushed
the
fix/unicode-input-read
branch
from
e029da2 to
6c71085
Compare
the-mikedavis
left a comment
the-mikedavis
left a comment
There was a problem hiding this comment.
Thanks! (Sorry for the delay, this got trapped under a pile of other notifications 😅.)
And great to keep the docs/windows-vt.md doc up to date. This is something I really wish Microsoft would document, even if it were just C++ code samples. I'm not sure I've seen a good example that fully covers reading VT.
|
No worries, thanks! I agree - I've had a pretty difficult time trying to make sense of all the quirks between the legacy and VTE input reader modes. Code samples and more detailed explanations of the tradeoffs would be most welcome. |
2 participants
The value returned from
GetNumberOfConsoleInputEventsmatches what you would get when callingReadConsoleInputW, but this does not always match the number of results fromReadConsoleInputAwhen typing some Unicode characters that differ in UTF-8/UTF-16 encoding. As a result, some Unicode characters were not fully read on the initial keystroke and did not show up until you typed them twice. Thankfully,ReadConsoleInputAtells us how many results are returned anyway, so we can just initialize it with a sufficiently large buffer and only useGetNumberOfConsoleInputEventsto determine if there are >0 pending events.This should fix the reports from people claiming they had to type in certain keys more than once or some characters weren't appearing (helix-editor/helix#14637 (comment), helix-editor/helix#14363 (comment)). I wasn't able to reproduce the IME input hanging (helix-editor/helix#14387), so I'm not sure if this will be fixed, but it might.
The other issues on Windows, such as certain keys like
<Ctrl-,>not working, will still require implementing the legacy protocol for some users, since Windows Terminal (among others) doesn't implement the Kitty Keyboard protocol. I'm working on this in another branch.