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

[antoineco]

Environment

Windows build number: 10.0.19042.746
Windows Terminal version: 1.6.10272.0 (current Preview version from Microsoft Store)

Ubuntu WSL distribution from the Microsoft Store: 2004.2020.812.0
tmux: 3.0a (from Ubuntu's APT package repo)

Steps to reproduce

1. Open a WSL terminal

2. Run a new tmux session:

$ tmux

3. Generate some output. Here a sample output from the command I ran while running into this, for your convenience

$ cat <<EOF
Install Kubernetes apps from helm charts or YAML files using the "install"
command.

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/do-token
EOF

4. Press Enter multiple times, until the output disappears from the current window.

5. Enter tmux's copy mode with Ctrl-B [

Note: first Ctrl-B, then [. Not simultaneously

6. Scroll up with arrow keys or PgUp

7. Copy the previously generated output.

8. (optional) Press q to exit tmux's copy mode.

Expected behavior

The copied text contains line breaks at the end of each line.

In this case, I'm expecting:

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

Actual behavior

This is the raw pasted text. Notice the spaces before "Aliases" instead of the new line (I can replicate the issue with any text, not only that one):

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

ℹ️ Important note: this happens only in tmux's copy mode. After pressing q, copying the same output will work as expected.

[zadjii-msft]

Wait hold up, isn't this #8532?

/cc @DHowett

[antoineco]

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

[DHowett]

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.

[antoineco]

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

[DHowett]

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.

[antoineco]

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

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.

[zadjii-msft]

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

[thammegowda]

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.

[crmky]

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.