Text Wrapping with ConPTY #615

@davidhewitt commented on GitHub (Apr 4, 2019):

Thanks for the notes!

I did have a search for an existing issue before opening though didn't spot one. Please do close this issue if a duplicate turns up!

@davidhewitt commented on GitHub (Apr 4, 2019): Thanks for the notes! I did have a search for an existing issue before opening though didn't spot one. Please do close this issue if a duplicate turns up!

claunia commented

@jzabroski commented on GitHub (Apr 16, 2019):

Interesting. This feature request dovetails nicely with my recent remarks on MSBuild supporting colors but intermediary programs like PowerShell blocking colors: https://github.com/Microsoft/msbuild/issues/4299

I am still wrapping my head around all of this, so apologies to those who don't see the same connection I see, which is that API consumers don't control output, API providers do. I think this is a fundamental problem.

@jzabroski commented on GitHub (Apr 16, 2019): Interesting. This feature request dovetails nicely with my recent remarks on MSBuild supporting colors but intermediary programs like PowerShell blocking colors: https://github.com/Microsoft/msbuild/issues/4299 I am still wrapping my head around all of this, so apologies to those who don't see the same connection I see, which is that API consumers don't control output, API providers do. I think this is a fundamental problem.

claunia commented

@Tyriar commented on GitHub (May 31, 2019):

This is one of the major issues VS Code has with ConPTY as we have to guess which lines wrap (based on a naive heuristic) to try to avoid issues like https://github.com/microsoft/vscode/issues/43664

@Tyriar commented on GitHub (May 31, 2019): This is one of the major issues VS Code has with ConPTY as we have to guess which lines wrap (based on a [naive heuristic](https://github.com/xtermjs/xterm.js/blob/32d6613811e403b3693d004b86c8a664553eaa59/src/WindowsMode.ts#L11-L29)) to try to avoid issues like https://github.com/microsoft/vscode/issues/43664

claunia commented

@ExE-Boss commented on GitHub (May 31, 2019):

@Tyriar Well, that heuristic doesn’t work well at all with a PowerLine prompt that has right‑aligned blocks.

Also, are you sure you didn’t mean to say WinPTY? Because that is what the comment in the linked code mentions.

@ExE-Boss commented on GitHub (May 31, 2019): @Tyriar Well, that heuristic doesn’t work well at all with [a PowerLine prompt](https://github.com/Jaykul/PowerLine/blob/master/README.md) that has [right‑aligned blocks](https://github.com/Jaykul/PowerLine/blob/master/README.md#right-aligned-blocks). Also, are you sure you didn’t mean to say WinPTY? Because that is what the comment in the linked code mentions.

claunia commented

@Tyriar commented on GitHub (May 31, 2019):

@ExE-Boss its primary uses are link detection and error detection so that doesn't matter too much. Problems arise for example when errors have unfortunately placed spaces at the end of a wrapped line, leading to flaky detection.

@Tyriar commented on GitHub (May 31, 2019): @ExE-Boss its primary uses are link detection and error detection so that doesn't matter too much. Problems arise for example when errors have unfortunately placed spaces at the end of a wrapped line, leading to flaky detection.

claunia commented

@Tyriar commented on GitHub (May 31, 2019):

winpty acts in the same way as conpty, the workaround is for both.

@Tyriar commented on GitHub (May 31, 2019): winpty acts in the same way as conpty, the workaround is for both.

claunia commented

2026-01-30 21:57:00 +00:00

@wolf99 commented on GitHub (Oct 1, 2019):

Per https://github.com/microsoft/vscode/issues/81328, this is breaking problem matchers in VS Code in the case where the user has not already opened the terminal.

@wolf99 commented on GitHub (Oct 1, 2019): Per https://github.com/microsoft/vscode/issues/81328, this is breaking problem matchers in VS Code in the case where the user has not already opened the terminal.

claunia commented

@jzabroski commented on GitHub (Oct 1, 2019):

API Consumers need to control output formatting, not API Producers.

@jzabroski commented on GitHub (Oct 1, 2019): API Consumers need to control output formatting, not API Producers.

claunia commented

2026-01-30 21:57:00 +00:00

@zadjii-msft commented on GitHub (Oct 1, 2019):

Okay, we're not disagreeing that this should be fixed. However, no one on the team has had the time to get to it quite yet. If a particularly passionate community member is interested in contributing, we'd be happy to review a PR.

@zadjii-msft commented on GitHub (Oct 1, 2019): Okay, we're not disagreeing that this should be fixed. However, no one on the team has had the time to get to it quite yet. If a particularly passionate community member is interested in contributing, we'd be happy to review a PR.

claunia commented

2026-01-30 21:57:01 +00:00

@Biswa96 commented on GitHub (Oct 1, 2019):

Which source file or project or function handle the text wrapping in normal CMD + ConHost combo?

@Biswa96 commented on GitHub (Oct 1, 2019): Which source file or project or function handle the text wrapping in normal CMD + ConHost combo?

claunia commented

2026-01-30 21:57:01 +00:00

@zadjii-msft commented on GitHub (Oct 1, 2019):

@Biswa96 this is probably less about the wrapping within conhost itself, but more about how ConPTY renders wrapped text. I'd probably take a look at XtermEngine::PaintBufferLine, which is where conpty draws a particular run of text. Currently, whenever we reach the end of a line, we're always going to emit a \n to move the cursor to the next line. We probably shouldn't, because that's causing hard line breaks.

In my original prototype, I believe I added a flag wasWrapped, which the Renderer passes to the various IRenderEngines, including the VtEngines. What we'd need to do is make sure that when a run of text is painted that was wrapped, we don't move the cursor (with _MoveCursor) immediately following that. Instead, we should just assume the subsequent text we need to render was on the next line.

@zadjii-msft commented on GitHub (Oct 1, 2019): @Biswa96 this is probably less about the wrapping within conhost itself, but more about how ConPTY renders wrapped text. I'd probably take a look at `XtermEngine::PaintBufferLine`, which is where conpty draws a particular run of text. Currently, whenever we reach the end of a line, we're always going to emit a `\n` to move the cursor to the next line. We probably shouldn't, because that's causing hard line breaks. In my original prototype, I believe I added a flag `wasWrapped`, which the Renderer passes to the various `IRenderEngine`s, including the `VtEngine`s. What we'd need to do is make sure that when a run of text is painted that was wrapped, we don't move the cursor (with `_MoveCursor`) immediately following that. Instead, we should just _assume_ the subsequent text we need to render was on the next line.

claunia commented

2026-01-30 21:57:02 +00:00

@Tyriar commented on GitHub (Feb 27, 2020):

@zadjii-msft in what Windows version should this be expected? I think I'll need to disable the special compatibility mode in VS Code that guesses wrapped lines based on the build number.

@Tyriar commented on GitHub (Feb 27, 2020): @zadjii-msft in what Windows version should this be expected? I think I'll need to disable the special compatibility mode in VS Code that guesses wrapped lines based on the build number.

claunia commented

2026-01-30 21:57:02 +00:00

@DHowett-MSFT commented on GitHub (Feb 27, 2020):

@Tyriar the version what comes after 19041.

@DHowett-MSFT commented on GitHub (Feb 27, 2020): @Tyriar the version what comes after 19041.

claunia commented

2026-01-30 21:57:02 +00:00

@davidhewitt commented on GitHub (Feb 27, 2020):

Thanks very much! Thrilled to see this. I guess until stable release I'll also be able to enjoy it on insiders ;)

@davidhewitt commented on GitHub (Feb 27, 2020): Thanks very much! Thrilled to see this. I guess until stable release I'll also be able to enjoy it on insiders ;)

claunia commented

@aytey commented on GitHub (Apr 21, 2021):

@davidhewitt in case you're interested, I implemented the xterm.js (== VS Code) "naïve heuristic" in Alacritty here:

This change resolves the issue with copying (e.g.,) ~/.ssh/id_rsa.pub but also preserves the newlines when copying files that do have genuine \n (e.g., cat ~/.zshrc).

@aytey commented on GitHub (Apr 21, 2021): @davidhewitt in case you're interested, I implemented the xterm.js (== VS Code) "[naïve heuristic](https://github.com/xtermjs/xterm.js/blob/32d6613811e403b3693d004b86c8a664553eaa59/src/WindowsMode.ts#L11-L29)" in Alacritty here: - [https://github.com/andrewvaughanj/alacritty/commit/dc24686f5b9f327b8beb5e5cb7beeac759a8660a](https://github.com/andrewvaughanj/alacritty/commit/dc24686f5b9f327b8beb5e5cb7beeac759a8660a) - [https://github.com/andrewvaughanj/alacritty/tree/windows_copy_long_lines](https://github.com/andrewvaughanj/alacritty/tree/windows_copy_long_lines) This change resolves the issue with copying (e.g.,) `~/.ssh/id_rsa.pub` but also preserves the newlines when copying files that do have genuine `\n` (e.g., `cat ~/.zshrc`).

claunia commented

@wesley800 commented on GitHub (Nov 25, 2022):

@DHowett-MSFT Hi, I wonder if the fix (#4415) applies to conhost.exe on Windows newer than 19041? I've tested it on 19044 with ConPty APIs, and got \r\ns between segments of wrapped lines (output by sending echo LONG...LINE\r to powershell). I've placed my test code snippet at https://github.com/wesley800/rust-conpty-test .

I've briefly checked the code of #4415 and it seems that all changes relates to the WindowsTerminal part, rather than the conhost part. But I'm not familar with the whole architecture of the source tree. So if it does changed the behaviour of conhost, what sould I do if I want to decide whether a line is wrapped, or just happens to holds a line with same width to the window and a following hard break?

Actually this is from https://github.com/alacritty/alacritty/issues/2093 . I also tested with latest alacritty on 19044 and found it still gives breaked lines when copying content from the window, such as ssh public keys.

Update: this seems to be already fix on Win11. Output files are attached to https://github.com/wesley800/rust-conpty-test/tree/master/output .

Update2: A pre-compiled binary is added to the repo for those not familiar with rust toolchain.

@wesley800 commented on GitHub (Nov 25, 2022): @DHowett-MSFT Hi, I wonder if the fix (#4415) applies to conhost.exe on Windows newer than 19041? I've tested it on 19044 with ConPty APIs, and got `\r\n`s between segments of wrapped lines (output by sending `echo LONG...LINE\r` to powershell). I've placed my test code snippet at https://github.com/wesley800/rust-conpty-test . I've briefly checked the code of #4415 and it seems that all changes relates to the WindowsTerminal part, rather than the conhost part. But I'm not familar with the whole architecture of the source tree. So if it does changed the behaviour of conhost, what sould I do if I want to decide whether a line is wrapped, or just happens to holds a line with same width to the window and a following hard break? Actually this is from https://github.com/alacritty/alacritty/issues/2093 . I also tested with latest alacritty on 19044 and found it still gives breaked lines when copying content from the window, such as ssh public keys. Update: this seems to be already fix on Win11. Output files are attached to https://github.com/wesley800/rust-conpty-test/tree/master/output . Update2: A pre-compiled binary is added to the repo for those not familiar with rust toolchain.

claunia commented

@aytey commented on GitHub (Nov 27, 2022):

@wesley800:

Update: this seems to be already fix on Win11. Output files are attached to https://github.com/wesley800/rust-conpty-test/tree/master/output .

How did you perform this test? Just using a latest Alacritty build on stock Windows 11? What version of Windows 11?

@aytey commented on GitHub (Nov 27, 2022): @wesley800: > Update: this seems to be already fix on Win11. Output files are attached to https://github.com/wesley800/rust-conpty-test/tree/master/output . > How did you perform this test? Just using a latest Alacritty build on stock Windows 11? What version of Windows 11?

claunia commented

@wesley800 commented on GitHub (Nov 27, 2022):

How did you perform this test? Just using a latest Alacritty build on stock Windows 11? What version of Windows 11?

I don't know, probably the latest one. I don't have access to that machine in fact. I've confirmed that both latest Alacritty and rust-conpty-test shows no CR or LF at line wrapping points.

@wesley800 commented on GitHub (Nov 27, 2022): > How did you perform this test? Just using a latest Alacritty build on stock Windows 11? What version of Windows 11? I don't know, probably the latest one. I don't have access to that machine in fact. I've confirmed that both latest Alacritty and [rust-conpty-test](https://github.com/wesley800/rust-conpty-test/tree/master/output) shows no CR or LF at line wrapping points.

claunia commented

2026-01-30 21:57:04 +00:00

@wesley800 commented on GitHub (Dec 4, 2022):

@zadjii-msft In case no one is still watching this issue...

@wesley800 commented on GitHub (Dec 4, 2022): @zadjii-msft In case no one is still watching this issue...

claunia commented

@zadjii-msft commented on GitHub (Dec 5, 2022):

Sorry, still catching up on mail after the holidays.

I'd assume just based on the dates that #4415 would be in at least 19042 - it's at around this point in time that tracking code changes across win10 versions vs win11 versions starts getting a little more confusing... I can try and drill in and find where the commit to the OS repo is, but this should definitely be in 19044 and Windows 11, that I'm sure of.

That code change is mostly a Conhost / ConPTY change - the bulk of the real change is in the VT renderer, which is what conpty uses to write the buffer to a connected terminal application[1]

We do have a number of ongoing issues with line wrapping across the repo. https://github.com/microsoft/terminal/issues/6901#issuecomment-1307781312 has a collection of issues we've been seeing. It's hard to tease those apart to individual root causes, unfortunately. My headcannon is that there's some renderer state that's not getting set/reset correctly, resulting in the incorrectness of it all, but it's been hard to get exact repros.

Maybe there's something to do with the volume of text written in a single frame? hard to say.

[1] this is a vast oversimplification for the sake of brevity.

@zadjii-msft commented on GitHub (Dec 5, 2022): Sorry, still catching up on mail after the holidays. I'd assume just based on the dates that #4415 would be in at least 19042 - it's at around this point in time that tracking code changes across win10 versions vs win11 versions starts getting a little more confusing... I can try and drill in and find where the commit to the OS repo is, but this should _definitely_ be in 19044 and Windows 11, that I'm sure of. That code change is mostly a Conhost / ConPTY change - the bulk of the real change is in the VT renderer, which is what conpty uses to write the buffer to a connected terminal application[1] We do have a number of ongoing issues with line wrapping across the repo. https://github.com/microsoft/terminal/issues/6901#issuecomment-1307781312 has a collection of issues we've been seeing. It's hard to tease those apart to individual root causes, unfortunately. My headcannon is that there's some renderer state that's not getting set/reset correctly, resulting in the incorrectness of it all, but it's been hard to get exact repros. Maybe there's something to do with the volume of text written in a single frame? hard to say. [1] _this is a vast oversimplification for the sake of brevity._

claunia commented

2026-01-30 21:57:04 +00:00

@wesley800 commented on GitHub (Dec 7, 2022):

Thank you for your time and detailed replies to my each question and hope I didn't break your vacation much.

Actually I ran the test on Win10 LTSC 2022 which is 19044 by winver but don't know if the SKU matters.

Also I might be wrong in the expectation of #4415, which seems to be mainly focused on rendering (as you've stated). From my perspective, changes are mostly among adding lineWrapped flag into the state storage of ConPty, but nowhere relating to dismiss the "fake" line breaks at line wrapping points when ConPty writes to it's output pipe. I assume that's because I have not complete insight of the whole repo though.

@wesley800 commented on GitHub (Dec 7, 2022): Thank you for your time and detailed replies to my each question and hope I didn't break your vacation much. Actually I ran the test on Win10 LTSC 2022 which is 19044 by `winver` but don't know if the SKU matters. Also I might be wrong in the expectation of #4415, which seems to be mainly focused on rendering (as you've stated). From my perspective, changes are mostly among adding `lineWrapped` flag into the state storage of ConPty, but nowhere relating to dismiss the "fake" line breaks at line wrapping points when ConPty writes to it's output pipe. I assume that's because I have not complete insight of the whole repo though.

claunia commented

2026-01-30 21:57:04 +00:00

@zadjii-msft commented on GitHub (Dec 7, 2022):

hope I didn't break your vacation much

Nah it's fine, I'm just still slow coming back off paternity and only working like, half time. It's generally the holidays, so things are just slow here 😅 sorry for any delays!

You might have something here. We should probably take a look through the history here. Why is performedSoftWrap never used? #5181 might be relevant here.

I'll need to double tap on this.

That also being said - it looks like on windows 11 the test works fine? Perhaps the fixes I'm thinking of didn't actually land till 22000. This might just be another point in favor of having a proper ConPTY nuget package, that folks can use to consume the updated ConPTY version (regardless of OS version).

@zadjii-msft commented on GitHub (Dec 7, 2022): > hope I didn't break your vacation much Nah it's fine, I'm just still slow coming back off paternity and only working like, half time. It's generally the holidays, so things are just slow here 😅 sorry for any delays! <hr> You might have something here. We should probably take a look through the history here. Why is `performedSoftWrap` never used? #5181 might be relevant here. I'll need to double tap on this. <hr> That also being said - it looks like on windows 11 the test works fine? Perhaps the fixes I'm thinking of didn't actually land till 22000. This might just be another point in favor of having a proper ConPTY nuget package, that folks can use to consume the updated ConPTY version (regardless of OS version).

claunia commented

@std-move commented on GitHub (Jul 14, 2023):

@zadjii-msft Any chance this could get fixed in Win10 19044/19045? The regular editions are supported at least till 2025-10-14, with IoT Enterprise LTSC (for which volume licencing is newly available) supported until 2032-01-13.

It seems like a bug that should be fixed as part of a cumulative update.

@std-move commented on GitHub (Jul 14, 2023): @zadjii-msft Any chance this could get fixed in Win10 19044/19045? The regular editions are supported at least till 2025-10-14, with IoT Enterprise LTSC (for which volume licencing is newly available) supported until 2032-01-13. It seems like a bug that should be fixed as part of a cumulative update.

claunia commented

@DHowett commented on GitHub (Jul 15, 2023):

It seems like a bug that should be fixed as part of a cumulative update.

I agree with you! Unfortunately, the Windows organization doesn't necessarily agree. Changes like this -- especially ones that are in vanishingly rare cases that come with a high likelihood of destabilizing a working product -- are very difficult to get into a servicing update without a strong "business justiciation."

The way we're tackling getting ConPTY bug fixes out to people on a quicker cadence than Windows releases is over in #15065: a NuGet package for folks to depend upon. 😄

@DHowett commented on GitHub (Jul 15, 2023): > It seems like a bug that should be fixed as part of a cumulative update. I agree with you! Unfortunately, the Windows organization doesn't necessarily agree. Changes like this -- especially ones that are in vanishingly rare cases that come with a high likelihood of destabilizing a working product -- are very difficult to get into a servicing update without a strong "business justiciation." The way we're tackling getting ConPTY bug fixes out to people on a quicker cadence than Windows releases is over in #15065: a NuGet package for folks to depend upon. :smile:

claunia commented

@Walms commented on GitHub (Jun 20, 2024):

It seems like a bug that should be fixed as part of a cumulative update.

I agree with you! Unfortunately, the Windows organization doesn't necessarily agree. Changes like this -- especially ones that are in vanishingly rare cases that come with a high likelihood of destabilizing a working product -- are very difficult to get into a servicing update without a strong "business justiciation."

The way we're tackling getting ConPTY bug fixes out to people on a quicker cadence than Windows releases is over in #15065: a NuGet package for folks to depend upon. 😄

I'm hitting problems using the Alacritty terminal. https://github.com/alacritty/alacritty/issues/4993

Is there anyway I can get the latest version to make that bug go away?

@Walms commented on GitHub (Jun 20, 2024): > > It seems like a bug that should be fixed as part of a cumulative update. > > I agree with you! Unfortunately, the Windows organization doesn't necessarily agree. Changes like this -- especially ones that are in vanishingly rare cases that come with a high likelihood of destabilizing a working product -- are very difficult to get into a servicing update without a strong "business justiciation." > > The way we're tackling getting ConPTY bug fixes out to people on a quicker cadence than Windows releases is over in #15065: a NuGet package for folks to depend upon. 😄 I'm hitting problems using the Alacritty terminal. https://github.com/alacritty/alacritty/issues/4993 Is there anyway I can get the latest version to make that bug go away?

claunia commented