6

Interestingly enough, this has also been a tmux issue for some: http://daemonforums.org/showthread.php?t=7311

But currently I am sticking to screen, and I'd like to know how I can make screen "behave" in that respect.

Selecting text with the mouse is no problem unless the line gets longer than the width of the pane. I've already tried to experiment with :width, with and without the -w option. (wrap is on, otherwise it will look like a mess (:+wrap))

Oh, and :width is VERY picky about the setting. If you set width too high, long lines will cause the whole terminal to shift back and forth (i. e. if your bash prompt is user@host $ it will only display as r@host $), which looks extremely ugly.

Selecting a long line that splits up into several times the pane width will result in the following behavior:

  • Selector (inverse) will display beyond the left pane, overlapping into the right pane. This looks buggy, to begin with. Selector too should wrap at the right border of the pane.
  • Pasting the selection will sometimes cause a long line to be cut off at the first partial line, truncating the rest; and sometimes even try to add | (!), trying to continue the line as if it was a multiline script (result: bash: syntax error near unexpected token '|') Argh.

Can't this be made work somehow even when using the mouse?

1 Answer 1

3

Short answer: no, GNU screen cannot do this.

Long answer: GNU screen largely ignores the xterm mouse protocol, except for a special case where it accepts mouse clicks (the "mousetrack" feature).

To make selection work as you suggest would take a lot more work:

  • The xterm mouse protocol works by making the terminal send escape sequences to your application.
  • screen uses only the "normal" mouse protocol (1000), which sends an escape sequence when a mouse button is pressed, and another escape sequence when (any) mouse button is released.
  • just clicks like that will not support the sort of dragging that you expect when selecting/pasting. So screen doesn't try to do anything in that regard.
  • when the xterm mouse protocol is active, you cannot do select/paste unless you use a shift mouse button.
  • either way (whether you turn mousetrack on, or not), screen relies upon the terminal to show selection highlighting. xterm (and other terminals) do not have a way to set selection-margins, so you get the full width of the screen highlighted.

In contrast, tmux does more with the mouse. It actually translates between the different types of xterm mouse protocol to provide for differences between terminals, e.g., choosing between UTF-8 mode (1005) and SGR (1006).

In principle, tmux could be modified to also provide an enhanced select/paste as described in this question, because it can set the xterm mouse-mode to 1002 (cell motion mouse tracking), which would tell it where to paint its own highlighting. I don't see it implemented in the source-code, so your link to How does tmux select contents only in one pane ? seems still relevant.

The (keyboard) copy mode in tmux, for instance, seems unaware of panes.

There are drawbacks:

  • it would be slow: much slower than copy mode because (a) there are more characters sent back from your terminal and (b) your expectations of performance using a mouse would be biased. This would very noticeable if you didn't happen to be running on a local machine but via ssh.
  • the selection would only be useful to tmux, e.g., usually wouldn't be copied to other windows in your X environment.

Further reading:

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .