terminal: Window line-wrapping can cause colored output to break copied text

Windows Terminal version

1.17.11461.0

Windows build number

10.0.22621.0

Other Software

bat 0.19.0

Steps to reproduce

I have found this very specific scenario for reproducing the issue reliably:

Install bat.

Create EXAMPLE.md with the following contents (including the markdown code fence, because we want syntax highlighting to color the output):

```shell
echo '1 22 333 4444 55555 666666 7777777 88888888 999999999 0000000000 1 22 333 4444 55555 666666 7777777 88888888 999999999 0000000000'
```

Resize the terminal to be narrower than that long echo line.

Run the following:

/usr/bin/batcat --color=always --style=header --decorations=always EXAMPLE.md

Copy the output.
Paste the output in a wider window.

It’s worth noting that it works fine (i.e. “as expected”) if the window is wide enough to not wrap when the command is run. If I resize the window later, the problem is not there.

Something that really surprises me is that piping the output via cat fixes the issue while looking exactly the same visually:

This bug is very similar to, or actually the same as, #5113.

Expected Behavior

For clarity, I think we need to distinguish between the line breaks introduced by Windows Terminal for the purposes of displaying a long line in a wrapped format and the line breaks that are part of the original string. I will call them wrapping line breaks and string line breaks respectively.

When copying a string from the terminal, I expect to copy the string line breaks but not the wrapping line breaks, so that when I paste it I get the “original” string (not the one with line wrappings).

Actual Behavior

When I copy text under these circumstances, it keeps the wrapping line breaks as well as he string line breaks.

About this issue

Original URL
State: closed
Created 9 months ago
Comments: 17 (6 by maintainers)

Most upvoted comments

At the very least, there are a couple issues here.

bat is emitting hard line breaks.
When you resize, sometimes Terminal unwraps a line of text even though it shouldn’t. This is reproduceable with…
- PowerShell: "a"*$host.ui.rawui.windowsize.width

for 1

When I copy text under these circumstances, it keeps the wrapping line breaks as well as he string line breaks.

This is because bat is emitting hard line breaks, visible below:

for 2

Now, we should not treat hard wrapped lines as wrapped text under any circumstances. However, we used to have an issue where text would unwrap on resize even though we knew it had a hard line break[^1]

I can reproduce this in 1.17 (where you originally filed the bug):

… and in 1.18 …

but not in 1.19 (preview) or 1.20 (canary):

If I try your repro from script (thanks for sharing it!) on 1.19, it no longer unwraps when I resize it 😃

(window width 76 as specified in repro)

(window resized to larger)

That is what @j4james was saying was a bug. Resize should have never unwrapped the lines, which would have made it more obvious that bat was inserting hard line breaks. 😁

[^1]: The resizing code was… uh. It was not great. It is much better now!

DHowett on Nov 16, 2023

@j4james I cannot reproduce it in 1.19.3172.0.

Pretty sure I did reproduce it in Terminal Preview before, but maybe not. ¯\_(ツ)_/¯

EDIT: I think I know what I did wrong last time I “reproduced” it in Preview! I think that was before I realized that bat actually produced a newline character. So I tried copy-pasting (which I thought was the bug), but i did not try to resize the window (which was the actual bug).

lindhe on Nov 17, 2023

Looks like the bat utility inserts hard line breaks. This issue on the bat repository might be helpful: https://github.com/sharkdp/bat/issues/897

Thanks for filing!

carlos-zamora on Nov 15, 2023

It looks like there was a typo in Mike’s link. It should be: https://github.com/microsoft/terminal/wiki/Troubleshooting-Tips#enabling-the-debug-tap

j4james on Oct 26, 2023

Can you try repro’ing this with the debug tap to get a trace of all the input and output? Once the bug starts occurring, send us a screenshot/copy-paste of the output and we might be able to figure out what the Terminal thinks it’s getting here.

zadjii-msft on Oct 25, 2023

It is beyond be how there can be a line wrap that affects copying but not resizing. Do you have any clue how that’s possible?

The fact that the resizing “works” for you is actually a bug. When you have a line that’s the exact width of the screen, it is mistakenly considered to be wrapping when the screen is resized (see issue #3088). That was supposed to have been fixed recently, but it still doesn’t seem to be working correctly in Windows Terminal.

j4james on Oct 15, 2023