Line breaks are ignored inconsistently when copying text in tmux copy mode #12335

@zadjii-msft commented on GitHub (Feb 1, 2021):

Wait hold up, isn't this #8532?

/cc @DHowett

@zadjii-msft commented on GitHub (Feb 1, 2021): Wait hold up, isn't this #8532? /cc @DHowett

claunia commented

@antoineco commented on GitHub (Feb 1, 2021):

@zadjii-msft no, it happens with any Unix command, contrary to what I though. The example in #8532 was arguably a bad a example, so I opened a new issue with a better repro.

@antoineco commented on GitHub (Feb 1, 2021): @zadjii-msft no, it happens with any Unix command, contrary to what I though. The example in #8532 was arguably a bad a example, so I opened a new issue with a better repro.

claunia commented

@DHowett commented on GitHub (Feb 1, 2021):

Here's the deal: If tmux is aware of the copy (it is handling selection and displaying the count/range of selected characters), that is completely outside of our control. We're forwarding mouse events off to tmux, and it is sending us back a base64-encoded version of what you selected. We turn that into UTF-8 and slap it directly onto your clipboard -- no further transformation is done.

If tmux is not aware of the copy (you're holding down shift while selecting, it is not displaying the top right indicator you pointed out, and the selection looks "non-native" (like a transparent overlay on top of your screen)), then it's our problem.

It's only arguably our problem, however. Terminal multiplexers own the entire screen, and they get the final say as to how lines are laid out. If they're laid out in such a way as to think we've wrapped (or not wrapped), that's on them. It's completely untenable in some situations, too, for terminal-bound copy (that is: tmux unaware) to operate correctly e.g. when there are tmux panes in view. Right? So... I dunno.

@DHowett commented on GitHub (Feb 1, 2021): Here's the deal: If tmux is aware of the copy (it is handling selection and displaying the count/range of selected characters), that is _completely_ outside of our control. We're forwarding mouse events off to tmux, and it is sending us back a base64-encoded version of what you selected. We turn that into UTF-8 and slap it directly onto your clipboard -- no further transformation is done. If tmux is _not_ aware of the copy (you're holding down shift while selecting, it is not displaying the top right indicator you pointed out, and the selection looks "non-native" (like a transparent overlay on top of your screen)), then it's our problem. It's only _arguably_ our problem, however. Terminal multiplexers own the entire screen, and they get the final say as to how lines are laid out. If they're laid out in such a way as to think we've wrapped (or not wrapped), that's on them. It's completely untenable in some situations, too, for terminal-bound copy (that is: tmux unaware) to operate correctly e.g. when there are tmux panes in view. Right? So... I dunno.

claunia commented

@antoineco commented on GitHub (Feb 1, 2021):

Just to clarify, I have mouse support disabled in tmux. The count in the top right corner is shown because I entered copy mode with the key combination mentioned in the issue description.

In other words, tmux is not aware of the copy.

There is no pane involved here. I'm not expecting text to be copied properly when multiple panes are open, but in a fullscreen window this sounds like something any terminal should get right (at least none of the terminal emulators I've used on Windows and other platforms have this issue).

@antoineco commented on GitHub (Feb 1, 2021): Just to clarify, I have mouse support _disabled_ in tmux. The count in the top right corner is shown because I entered copy mode with the key combination mentioned in the issue description. In other words, tmux is not aware of the copy. There is no pane involved here. I'm not expecting text to be copied properly when multiple panes are open, but in a fullscreen window this sounds like something any terminal should get right (at least none of the terminal emulators I've used on Windows and other platforms have this issue).

claunia commented

@DHowett commented on GitHub (Feb 1, 2021):

I believe tmux copy mode is intended to be combined with actually copying using tmux's copying bindings. Second case currently applies. I agree that it's annoying and I do want it fixed, but it's another one in the class of "sometimes terminal gets confused about which lines wrap" bugs. @zadjii-msft can likely find the parent duplicate.

@DHowett commented on GitHub (Feb 1, 2021): I believe tmux copy mode is intended to be combined with _actually copying using tmux's copying bindings_. Second case currently applies. I agree that it's annoying and I do want it fixed, but it's another one in the class of "sometimes terminal gets confused about which lines wrap" bugs. @zadjii-msft can likely find the parent duplicate.

claunia commented

@antoineco commented on GitHub (Feb 1, 2021):

@DHowett copy mode is how you scroll in tmux. When you need to go back in history, you enter copy mode. If you have mouse support enabled this will happen when you actually scroll the mouse and you may not realize it, but it is still the same copy mode.

I would gladly use the tmux native copy if I could easily copy the contents of the buffer to the Windows clipboard, but in practice there is no good solution for that.

@antoineco commented on GitHub (Feb 1, 2021): @DHowett copy mode is how you scroll in tmux. When you need to go back in history, you enter copy mode. If you have mouse support enabled this will happen when you actually scroll the mouse and you may not realize it, but it is still the same copy mode. I would gladly use the tmux native copy if I could easily copy the contents of the buffer to the Windows clipboard, but in practice there is no good solution for that.

claunia commented

@antoineco commented on GitHub (Feb 2, 2021):

Not a plug for another project but just to clarify the behaviour I see in other terminal emulators. Here with mintty/wsltty.

Reproduce the behaviour explained in the issue description (n.b. native copy, mouse support still disabled in tmux):

Raw paste:

You can also find the post-install message for each app with the "info"
command.

Usage:
  arkade install [flags]
  arkade install [command]

Aliases:
  install, i

Examples:
  arkade install
  arkade install openfaas  --gateways=2
  arkade install inlets-operator --token-file /home/acotten/do-token

It always works, no matter how I resize the terminal window (n.b. the actual window, not a tmux pane). In Windows Terminal, the line breaks seem to be sensitive to the current window size.

@antoineco commented on GitHub (Feb 2, 2021): Not a plug for another project but just to clarify the behaviour I see in other terminal emulators. Here with [mintty/wsltty](https://github.com/mintty/wsltty/). Reproduce the behaviour explained in the issue description (_n.b. native copy, mouse support still disabled in tmux_): ![image](https://user-images.githubusercontent.com/3299086/106620178-9aef0e80-6571-11eb-9cda-3f42d9015a2c.png) Raw paste: ``` You can also find the post-install message for each app with the "info" command. Usage: arkade install [flags] arkade install [command] Aliases: install, i Examples: arkade install arkade install openfaas --gateways=2 arkade install inlets-operator --token-file /home/acotten/do-token ``` It always works, no matter how I resize the terminal window (_n.b. the actual window, not a tmux pane_). In Windows Terminal, the line breaks seem to be sensitive to the current window size.

claunia commented

@zadjii-msft commented on GitHub (Nov 8, 2022):

This kinda seems like it's a dupe of #6901?

@zadjii-msft commented on GitHub (Nov 8, 2022): This kinda seems like it's a dupe of #6901?

claunia commented

@thammegowda commented on GitHub (Dec 2, 2022):

I think I have the same problem: I copied some text from tmux copy/scroll mode (CTRL+B [) and pasted to Excel sheet .
My text which had many line breaks in terminal got pasted into a single row in Excel desktop app, thus ignoring line breaks after paste. Same thing with Sharepoint and Google sheets (Web apps).
When I exit CTRL+B [ mode and copy paste text bottom few lines (without scrolling up via CTRL+B [), the line breaks are preserved during the paste as expected.
I don't think this issue is dupe of #6901; the other issue seems to be about spurious additional line breaks than expected, where ass this issue is missing line breaks.

@thammegowda commented on GitHub (Dec 2, 2022): I think I have the same problem: I copied some text from tmux copy/scroll mode (`CTRL+B [`) and pasted to Excel sheet . My text which had many line breaks in terminal got pasted into a single row in Excel desktop app, thus ignoring line breaks after paste. Same thing with Sharepoint and Google sheets (Web apps). When I exit `CTRL+B [` mode and copy paste text bottom few lines (without scrolling up via CTRL+B [), the line breaks are preserved during the paste as expected. I don't think this issue is dupe of #6901; the other issue seems to be about spurious additional line breaks than expected, where ass this issue is missing line breaks.

claunia commented

@crmky commented on GitHub (Feb 10, 2024):

I still see this issue in 1.19.240130002.

I have narrow down the issue to the TERM settings. If I set TERM to either xterm-256color or ms-terminal, this issue is gone. Otherwise if I set it to either screen-256color or tmux-256color, when copying multiple lines from vim, windows terminal will merge them into a single line.

I tried to compare infocmp output for those terminal types, but I can't find out which field caused that behavior. But at least you may workaround this issue by setting TERM variable.

@crmky commented on GitHub (Feb 10, 2024): I still see this issue in `1.19.240130002`. I have narrow down the issue to the `TERM` settings. If I set `TERM` to either `xterm-256color` or `ms-terminal`, this issue is gone. Otherwise if I set it to either `screen-256color` or `tmux-256color`, when copying multiple lines from vim, windows terminal will merge them into a single line. I tried to compare `infocmp` output for those terminal types, but I can't find out which field caused that behavior. But at least you may workaround this issue by setting `TERM` variable.

claunia commented

@vadimkantorov commented on GitHub (May 12, 2025):

Same problem with TERM=screen :(

@vadimkantorov commented on GitHub (May 12, 2025): Same problem with `TERM=screen` :(

claunia commented

545eaf258d/src/terminal/adapter/adaptDispatch.cpp (L163-L168)

@DHowett commented on GitHub (May 13, 2025):

This is very likely to be an incoming duplicate of #17225. There is a comment in the code exactly where I'd expect to find this bug referring to #15602, which is a duplicate of #17225 (higher number because it has more information.)

TL;DR: we should set WrapForced when we write the character in cell W+1, but we set it when we write cell W.

@DHowett commented on GitHub (May 13, 2025): This is very likely to be an incoming duplicate of #17225. There is a comment in the code exactly where I'd expect to find this bug referring to #15602, which is a duplicate of #17225 (higher number because it has more information.) https://github.com/microsoft/terminal/blob/545eaf258d8d7a66717ac2ac9b1a1e37b271ad29/src/terminal/adapter/adaptDispatch.cpp#L163-L168 TL;DR: we should set WrapForced when we write the character in cell W+1, but we set it when we write cell W.

claunia commented

@DHowett commented on GitHub (May 13, 2025):

@lhecker in 17225, you enumerated a set of tests that failed because ConPTY's output changed. That was why we never removed the incorrect SetWrapForced on adaptDispatch.cpp:166.

Now that VtEngine is pushing up daisies, should we reevaluate removing this SetWrapForced? I think it will finally eliminate this class of issues.

@DHowett commented on GitHub (May 13, 2025): @lhecker in 17225, you enumerated a set of tests that failed because _ConPTY's output changed_. That was why we never removed the incorrect SetWrapForced on adaptDispatch.cpp:166. Now that VtEngine is pushing up daisies, should we reevaluate removing this SetWrapForced? I think it will finally eliminate this class of issues.

claunia commented