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.