Terminal: Text Wrapping with ConPTY

[davidhewitt]

It seems to me that output is line-wrapped by conhost before being sent through the ConPTY stdout pipe. This makes sense, though it has the unfortunate downside that in Alacritty we can't do the line-wrapping ourselves.

This wouldn't matter that much, but when selecting and copying text in Alacritty which has been line-wrapped by conhost, Alacritty isn't aware that the text was originally a single line and inserts a newline into the content placed on the clipboard.

Is it possible to disable the line wrapping by conhost?

(Perhaps this would be something that would naturally be in the "passthrough" mode I've seen mentioned elsewhere in this issue tracker?)

[zadjii-msft]

I'm sure there's another issue tracking this lying around somewhere...

There was actually a prototype of doing this for a few insider's builds but that caused some other regressions in behavior late in RS5. (For internal reference, see task 16485846 and bug 18123777).

This is definitely something we need to figure out how to get right.

[davidhewitt]

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!

[jzabroski]

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.

[Tyriar]

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

[ExE-Boss]

@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.

[Tyriar]

@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]

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

[wolf99]

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.

[jzabroski]

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

[zadjii-msft]

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.

[Biswa96]

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

[zadjii-msft]

@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.

[Tyriar]

@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.

[DHowett-MSFT]

@Tyriar the version what comes after 19041.

[davidhewitt]

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