Screen & xterm: how to select text with the mouse in one only pane when window is divided vertically

gnu-screensplitterminal-multiplexerxterm

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?

Best Answer

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.

Related Solutions

GNU Screen – How to Split Window Vertically

GNU Screen <4.01 may not support vertical split without a patch.
GNU Screen >4.01 supports vertical splitting.

The Patch is licensed under GPLv2. Some people say that the vertical split in GNU screen makes the application slow but I haven't tested. I use tmux (terminal multiplexer)

Bash – How to set up `screen` to modify the window title and xterm-window title

An incomplete solution would be to modify your $PS1 prompt once inside a GNU screen. Start by modifying your shell's RC file (ie ~/.bashrc). Look for a case statement that evaluates $TERM:

case "$TERM" in
xterm*|rxvt*)
    PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a\]$PS1"
    ;;
*)
    ;;
esac

Add the following prior to the catch all (ie *)):

screen)
    PS1='\e]0;\u@\h:\w\a\ek\u@\h:\w\e\\\u@\h:\w$(__git_ps1 "(%s)")\$ '
    ;;

This will modify your hardstatus: \e]0;...\a

This will modify your window title: \ek...\e\\

The hardstatus will not show up unless you have configured it to do so. For example, you could add the following to your .screenrc:

hardstatus alwayslastline

Complex hardstatus string options will continue to work. You can substitute your now dynamic stored hardstatus for the current window using %h:

hardstatus string '%{= kw}[ %h ] %=%{w}[ %{r}%l%{w} ]%{w}[%{y} %Y-%m-%d %C %A %{w}]%{w}'

This will set the hardstatus line to the stored hardstatus between two brackets on the left side of the screen and the CPU utilization to the right along with the date and time.

Example:

 [ username@host:~ ]                    [ 0.00 0.01 0.00 ][ 2012-11-27  4:13 PM ]

CAVEATS

This will most likely break your cursor offset in your shell's history recall. (Hit your up arrow a few times, then try to edit that line. You'll see what I mean.) This is because most shells use the length for $PS1, and this will include the non-printable characters added to $PS1.
This will most likely break the xterm title bar, "freezing" it to the last status set prior to running GNU screen. What is interesting is that applications like vim that update the title bar will continue to work.
Manually setting the screen title (ie C-A A) will still work until the command prompt is updated.

Best Answer

Related Solutions

GNU Screen – How to Split Window Vertically

Bash – How to set up `screen` to modify the window title and xterm-window title

Related Question