James Holderness

I believe this bug is dependent on the keyboard layout. I can reproduce it when using a German or French layout, but not with a UK or US English layout....

In case anyone is curious what's actually happening here, this is the basic sequence of events: 1. When the terminal pastes something, that content reaches conpty as a stream of...

> Calling `InputBuffer::WriteString` instead of `InputBuffer::Write` would solve this issue for Windows Terminal in particular. That's assuming Windows Terminal is always in win32 input mode, which isn't guaranteed. But looking...

> oh hey we missed something! The input records _are_ wrong, we've got both a character AND an INPUT_RECORD, which isn't what you want! > >  @zadjii-msft I don't...

Doh! Disregard that. I completely missed the bright green square highlighting the first `q` passed though as a regular character!

The more I think about this, the more I believe there may be a bigger problem with win32 input mode in general. Prior to the new passthrough, the terminal would...

This may seem like a contrived example, and it is, but it's based on a real issue I had when testing my sixel branch with the [sixel-bench](https://github.com/jerch/sixel-bench) benchmark. Much like...

Huh. That's weird. I wouldn't expect the Windows version to have any effect, but I wonder if it has something to do with the version of WSL you're using (I'm...

Here's the equivalent test case rewritten in C++ with a `WriteConsole` call. But it'll now need to be run from a Windows shell like `cmd` or `PowerShell`. ```cpp #include #include...

I should have mentioned I didn't expect to see the problem on the Windows version of Python, because I know it handles I/O differently to Linux, and the output gets...