Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I use vim inside tmux inside urxvt, and the mouse works perfectly well for clicking and selecting text, except when I want to click too far to the right.

It seems to be related to the distance in number of columns from the left. When I go beyond column ~200 (not sure about the exact number), clicking simply does nothing.

Note that it's not related to a vim window: with two vim windows taking ~150 columns each, clicking will not work after the ~50th column in the second window. It's related to the whole vim session.

Also note that clicking far away in a big tmux pane (>200 columns) works perfectly.

In my .tmux.conf I have this line:

set -g default-terminal "screen-256color"

and in my .vimrc I have this:

if &term =~ "^screen"
    autocmd VimEnter * silent !echo -ne "\033Ptmux;\033\033]12;7\007\033\\"
    let &t_SI = "\<Esc>Ptmux;\<Esc>\<Esc>]12;5\x7\<Esc>\\"
    let &t_EI = "\<Esc>Ptmux;\<Esc>\<Esc>]12;7\x7\<Esc>\\"
    autocmd VimLeave * silent !echo -ne "\033Ptmux;\033\033]12;14\007\033\\"
end

It changes the cursor's color depending on the editing mode of vim, and it works, meaning that tmux really sets $TERM to "screen-256color" — but I don't know if this has any relevance with my mouse problem.

I'm running Ubuntu 12.04, vim 7.3, tmux 1.6 and rxvt-unicode 9.14.

Does anybody have an idea about what is causing this problem? Thanks.

Update: I now use xterm and it works. I thought urxvt was required for unicode support, but believe it or not, xterm has unicode support too.

share|improve this question
    
Just throwing in my +1; I, too, experience this problem. It only manifests inside a vim that is inside a tmux; and it manifests regardless of the respective configuration files. (For me, it's precisely column 223 every time.) –  ELLIOTTCABLE May 1 at 0:35
    
I've hit up the tmux mailing-list; we'll see if this is a bug. sourceforge.net/p/tmux/mailman/message/34074071 –  ELLIOTTCABLE May 1 at 4:10
    
I updated the question to say that I've fixed the problem by switching to xterm. I know it's not the best solution but it works. –  paps May 2 at 2:42

2 Answers 2

It's due to limitations in the mouse reporting protocol in terminals: "The original X10 mouse protocol limits the C x and C y ordinates to 223 (=255 - 32)" see this link

share|improve this answer
    
This isn't the case (well, I mean, if so, it's due to tmux or vim making assumptions about this; not due to the implementation in the terminal); tmux panes are manipulable beyond column 223 in my Terminal.app on OS X, and vim windows are as well; it's only when one is placed inside the other that there are issues. –  ELLIOTTCABLE May 1 at 0:36
    
Confirmed: this is definitely a tmux issue. nano --mouse shows the same limitations as vim, but only inside tmux. –  ELLIOTTCABLE May 1 at 0:36
    
I'm talking about the control sequences, tmux is itself a kind of terminal emulator. It interprets control sequences. I never said it was a terminal bug –  piec May 4 at 9:08

So, thanks to Screwtape, I've got an answer for this. Reproduced below:


The original xterm mouse protocol only supports up to 223 columns and lines. Later versions of the protocol used UTF-8 encoding, which turned out to be a terrible idea, and more modern terminals support a completely different protocol based on the SGR escape sequence that's much more sane.

tmux automatically supports the original protocol and the SGR protocol both ways (to the terminal it's running inside of, and to the applications running inside it.) but it only requests UTF-8 mode from the outer terminal if 'mouse-utf8' is enabled in the config file.

You can use the vttest tool to experiment with different mouse protocols inside and outside tmux to get a better idea what's going on.

According to the documentation for Vim's 'ttymouse' option, it will ask the terminal for original-xterm-protocol support if $TERM is a variant of xterm, mlterm or screen (and tmux reports itself as screen, so that's OK). If the terminal supports the "RV" termcap feature to determine the xterm version number, Vim will use that to automatically upgrade to 'xterm2' or 'sgr' mouse protocols... but typically only xterm advertises "RV" support, so tmux is left out of the automatic upgrade process.

In my ~/.vimrc I have the following code to enable decent mouse support, instead of relying on Vim's autodetection:

" Screen/tmux can also handle xterm mousiness, but Vim doesn't
" detect it by default.
if &term == "screen"
set ttymouse=xterm2
endif

if v:version >= 704 && &term =~ "^screen"
" Odds are good that this is a modern tmux, so let's pick the
" best mouse-handling mode.
set ttymouse=sgr
endif

(Of note, the set ttymouse=sgr is the actual fix, here; I suggest adding it to your .vimrc as Tim did.)

share|improve this answer
1  
You can use has("mouse_sgr") instead of testing v:version >= 704 –  piec May 5 at 9:14
    
Using set ttymouse=sgr or set ttymouse=xterm2 does not work in tmux in urxvt. You still can't click past the 223 column. –  paps May 5 at 10:43
    
Hm, @paps, I don't have access to an urxvt to test. Can you check the other ttymouse values? And enable ⌃b :, then set mouse-utf8 on, in the tmux you're testing with, for me? –  ELLIOTTCABLE May 12 at 8:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.