James Holderness

OK, then it's not just the responses being out of order. It's possible the sequence is being corrupted by conpty's input statemachine, like the issue you fixed in [PR #16352](https://github.com/microsoft/terminal/pull/16352)....

@Tabiskabis That's interesting. This hadn't occurred to me, but running `edit.exe` (i.e. the Windows version) from within a WSL shell will force it to go through the system conpty, so...

@o-sdn-o I'm not sure those 16-byte chunks are a problem here (at least for the case where we run `edit.exe` from WSL) because otherwise the break would have occurred halfway...

@o-sdn-o But the app has no direct control over how fast the responses are being read, because it's conhost that is reading them and consuming them (I'm talking about the...

Just to be absolutely clear, the case I'm talking about was a win32 executable run from within a WSL shell. In that case there are two different conpty sessions: Windows...

But as far as I can see there's no data loss in your case. You're getting all the responses back, just split up across packets. If the app isn't handling...

I just realised there's another issue evident in the responses I'm seeing. The `DSR-CPR` response and `DA` response are actually out of order. This likely wouldn't be the case for...

@hzeller Last I checked (a build from last week) they didn't support the `XTVERSION` query, their `DA1` response indicated a VT102 (i.e. `\e[?6c`) and their `TERM` was set to `xterm-256color`....

It's assumedly because `timg` isn't a valid option for `--logo-type`. You can see the allowed values in the code here: https://github.com/fastfetch-cli/fastfetch/blob/305776eb947f778a34104cc0892fccd4d94779a6/src/options/logo.c#L55-L72 And also in the documentation here: https://github.com/fastfetch-cli/fastfetch/wiki/Logo-options#logo-types If you...

FYI, you've already got an issue for this "new" keyboard protocol (see #2770), which was developed 5 years ago, 8 months earlier than the kitty keyboard protocol that you're currently...