Tmux pane selection with mouse

charactersmodemousetmux

I have the following problem while using tmux under Ubuntu. I enabled mouse-mode to switch between panes by clicking the mouse, but the switching is not always successful, and random characters appear in my terminal.

screenshot:

My tmux.conf file:

unbind %
bind | split-window -h
bind - split-window -v

# Mouse mode
set -g mode-mouse on
set -g mouse-resize-pane on
set -g mouse-select-pane on
set -g mouse-select-window on
set mouse-utf8 off

# Active pane border colour
set-option -g pane-active-border-fg yellow

# Load layout
bind q source-file ~/.tmux/dev_laptop
bind Q source-file ~/.tmux/dev_mon

# Show Pane Number
set-option -g status-left '#P'

I'm using the latest tmux (version 1.7), and the problem is terminal independent (tried it with xterm, gnome-terminal, guake).

Others experienced the same problem, but the solutions didn't work for me:
1) http://code.google.com/p/iterm2/issues/detail?id=855
2) Why are random characters inserted into my tmux session?

Best Answer

I think you need to remove the line

set mouse-utf8 off

My environment is similar to yours. I use Ubuntu 12.10, Tmux 1.7, Gnome-terminal and Konsole. I don't have this problem without this line. I have not found character setting in Gnome-terminal but in Konsole it's Utf-8.

Side note: Don't use mouse, keyboard is much much faster.

Summary

The issue clearly starts with PuTTY, but it doesn't necessarily stop there. There is a link to a potential fix for the PuTTY issue below, as well as an analysis of the issue as a whole.

Issue Description

Configuration

vim with mouse=a enabled for scrolling, selection, and cursor movement

tmux, with no tmux mouse functionality enabled, i.e. the following:

set -g mode-mouse off
set -g mouse-select-pane off
set -g mouse-resize-pane off
set -g mouse-select-window off

Use Case

A typical use case is to use vim inside of tmux. Avoiding negative interactions between tmux and vim is one of the primary reasons to disable tmux scrolling.

Behavior

Please note that the following only occurs when using PuTTY as the terminal emulator, and is not reproducible in gnome-terminal or any other tested Linux terminal emulator.

When attempting to 'scroll up' using the mouse in vim inside of a tmux session, the action simply fails. As OP describes, it is often possible to see the buffer jerking 'up and down' as if there is a counter-action taking place with each scroll attempt (more on this below).

This is basically the same as OP's description, but recapped just in case something isn't clear in my explanation or OP's question.

Potential Solution -- PuTTY

There appears to be an issue where PuTTY sends an extraneous ScrollDown event with every ScrollDown/ScrollUp event. This means that each attempt to scroll up gets cancelled out and nothing happens. Conversely, when scrolling down, each scroll event is doubled. The behavior is easy to validate by looking at the vim scrolling behavior first outside of tmux (where scrolling works properly), and second inside of tmux (where scrolling up does not work, and a single attempt to scroll down scrolls twice as much).

According to the following gmane thread, the issue described above is resolved with a patch from Putty-X (https://github.com/atsepkov/putty-X/commit/bbcedf5a85ca1ccaa27005e7f7ebeb4c8a783b88):

Link to gmane thread: http://comments.gmane.org/gmane.comp.terminal-emulators.tmux.user/5498.

NOTE: I haven't validated the above solution myself, so please review the gmane thread for additional information.

Additional Observations

Where it really gets interesting is that this is a new issue not reproducible using older versions of tmux/vim. Using the same version of PuTTY (0.63), the issue can be actively demonstrated on an Ubuntu 13.10 system, while an Ubuntu 12.04 system does not exhibit the issue.

At first, the issue seems to point to a system configuration delta (i.e. missing ncurses-term or similar), but no fix has been identified using this type of solution. Furthermore, the multiple reports of this same issue (including this thread) tend to support the existence of the issue.

Because of the co-dependent nature of the issue and versions of the related software, it seems the issue isn't limited to a single application. It may be that a newer version of tmux/vim 'fixed' something that created a regression. Or, it may be that a newer version of tmux/vim simply exposed the existing issue in PuTTY. Either way, it will require some additional investigation to fully iron out. Please find some pertinent version information below if this can help anyone in their investigation.

Version Information

Ubuntu 12.04 version info ('scrolling up' in vim inside of tmux works):

tmux: 1.6-1
vim: 7.3.429-2

Ubuntu 13.10 version info ('scrolling up' in vim inside of tmux is broken):

tmux: 1.8-4
vim: 7.4.000-1

Also of note -- the gmane poster reported not observing the issue on tmux 1.7 + vim 7.3. Poster's first observation of the issue was also with tmux 1.8 + vim 7.4.

Hopefully, at the very least, this answer provides anyone dedicated to (or stuck with) PuTTY an option for working around this issue. Beyond that, hopefully someone can make sense of the additional observations above and help bring the topic to a proper resolution.

Disable mouse reporting in a terminal session after tmux exits unexpectedly

To send codes to the terminal from bash you can use the printf command. (You can also use echo, of course, but printf is generally better suited to sending terminal commands, since it has explicit support for sending ESC and makes it easier to separate the command characters from parameters, etc.)

Tmux, as well as most popular programs that support terminal mouse tracking, use XTerm Mouse Reporting (aka “X11 Mouse Reporting”).

To disable Mouse Reporting from bash, use this code:

printf '\e[?1000l'

ESC [ ? … l means “DEC Private Mode Reset (DECRST)” (the same code ending with an h instead of an l enables the feature).

There is also an older “X10 Mouse Reporting” protocol, which uses 9 instead of 1000, that can be disabled with ESC [ ? 9 l, but as far as I am aware you’re not likely to see this feature used for mouse tracking.

I normally use the Xterm Control Sequences documentation as my canonical reference for terminal codes and I recommend it, since it is both a practical guide to what XTerm supports and it is also the most comprehensive documentation of commonly supported codes that I've found.