77

I tend to maximize a terminal to one screen, and vertically split several windows in Vim. Everything works fine for the first few windows on the left, but clicking past about the 220th column in the terminal doesn't work correctly. Any mouse clicks past column 220 seem to be wrapping around to column 1. I've tested in xterm, urxvt, and Gnome terminal with and without tmux/screen; always the same behavior. If I greatly increase the size of the font in Gnome terminal, I can click on the last column (although it is no longer past column #220).

If I run a command in a terminal that prints to standard output, I can click all the way to the right of the terminal. The problem does seem to be related to Vim.

I have set mouse=a in .vimrc. I'll post the entire file on request, but it doesn't seem to have anything else related to the mouse.

It's probably irrelevant, but I'm running Xmonad+Gnome. Thanks in advance.

JJ Geewax
  • 10,342
  • 1
  • 37
  • 49
bhinesley
  • 2,259
  • 2
  • 18
  • 15
  • 1
    Open up a terminal and maximize it. Run `vim`, and then enter `230ix` and hit escape. Your font should be small enough that the `x`'s do not wrap. Clicking on any but the last dozen or so 'x' characters will cause that character to be selected. Clicking on any of the last few 'x' characters, however, will cause the `x` in column 1 to be selected (for me, at least). – bhinesley Aug 09 '11 at 20:52
  • It is a very strange behavior. I use urxvt and do not experience this problem at all, failing to reproduce it following your instructions. – ib. Aug 10 '11 at 00:55
  • Can't help, sorry, but I can confirm that I see the same behavior you describe with xterm, gnome-terminal, and rxvt. Looks like a bug to me? – PonyEars Aug 10 '11 at 01:09
  • Tried under Gnome, and a couple other window managers. Also, under gnome, I get an "Invalid register" error from vim when I click and drag (to select characters) past the 223rd column. – PonyEars Aug 10 '11 at 01:15
  • @redstreet: that's great, actually. At least there is good reason to believe that it is a bug. For the record, I'm running Fedora 15, Vim 7.3 compiled Mar 17 2011 including patches 1-138. I couldn't find an existing bug report, so I'll file one. – bhinesley Aug 10 '11 at 03:07
  • 1
    I've heard about this behavior before, something about mouse handling in the tty in general. Can you try opening another application that supports mouse interaction and see if it too has the same problem? – Randy Morris Aug 10 '11 at 10:38
  • @Randy Morris: I'd tried it earlier on the output of `ls` and it worked fine. However, I tested it just now in `w3m`, and encountered the same problem. It seems that if it were an issue with the tty, that it would have occurred when using the mouse after running `ls` as well. Confirming the issue in `w3m` does raise the question, though. Thoughts? – bhinesley Aug 10 '11 at 16:52
  • I'll look around and see if I can find the thread I originally read about this in but my efforts so far to find it have been unsuccessful. – Randy Morris Aug 10 '11 at 16:59
  • @Randy Morris found something: http://groups.google.com/group/vim_dev/browse_thread/thread/4c137e64d2032441/b3993eaa89589619?lnk=gst&q=mouse#b3993eaa89589619 – bhinesley Aug 15 '11 at 20:16

3 Answers3

107

This has been fixed in Vim 7.3.632. See :h sgr-mouse. Or just put this in your ~/.vimrc:

set ttymouse=sgr

If you want to be compatible with versions that don't have mouse_sgr compiled in, use:

if has("mouse_sgr")
    set ttymouse=sgr
else
    set ttymouse=xterm2
end

To see if your version of Vim has mouse_sgr, run vim --version from the command-line, or in Vim, enter :version, and look for +mouse_sgr.

If you're using older versions of screen, or terminal emulators that don't support SGR, you may need to upgrade or switch. These settings work with all new versions of screen, tmux, gnome-terminal, PuTTY/KiTTY, iTerm2, and Terminal.app, using TERM=xterm-256color or screen-256color.

Update: If you're using neovim, SGR support is enabled by default.

Jim Stewart
  • 16,964
  • 5
  • 69
  • 89
  • set ttymouse=sgr unfortunately doesn't work when using screen on OSX 10.10.3 with Vim 7.4 – Tom Jacques Apr 29 '15 at 19:38
  • I haven't tried that. Could be a problem with the OSX termcap entry for screen, could be a problem with Terminal.app, could be a problem with OSX's screen build. OSX tools like screen are woefully out-of-date; you might have better luck with MacPorts (or Homebrew, if you must). It works fine with iTerm2 + MacPorts tmux + MacPorts vim; that's what I use daily. I highly recommend you ditch screen and switch to tmux anyway. – Jim Stewart Apr 30 '15 at 20:40
  • 2
    Spent a while wrestling with this, but there is an answer: the version of screen that comes with OSX is, as you say, woefully out of date. By using the most recent version, you can get actual 256 color support, but it does not have sgr mouse support. However, there is a patch which adds support that can be applied to the current head: https://lists.gnu.org/archive/html/screen-devel/2014-04/msg00043.html Applying that patch and rebuilding, as well as setting ttymouse=sgr inside of vim has it all working nicely now. – Tom Jacques Apr 30 '15 at 20:56
  • 3
    Screen is entirely obsoleted by tmux, IMHO. Also, the [screen source](http://git.savannah.gnu.org/cgit/screen.git/tree/src/screen.c) is some of the scariest I've seen in a while. – bhinesley May 21 '15 at 17:31
  • I'm using terminal Vim 8.0.0851 with rxvt-unicode (urxvt) in Arch Linux. When I set use "set ttymouse=sgr", Vim goes from ignoring the right side of the terminal to "clicking" stuff on the left of the console whenever I click on the right side. – Synthead Aug 15 '17 at 22:34
  • It's almost certainly a problem with your terminal. It's probably moving the cursor to (column mod 255). Someone might have patched it. Try with xterm or a more modern terminal to confirm. Make sure your `TERM` is set correctly too. – Jim Stewart Aug 15 '17 at 23:14
  • 1
    @Synthead In your case use `set ttymouse=urxvt`, it's right there in `:h ttymouse`. – Walf Mar 08 '19 at 01:31
  • I don't know how many years of annoyance I could have avoided if I'd read this answer sooner...! – Sam Watkins Apr 10 '22 at 12:17
9

Edit:
I deleted the bug report, as that tracker was for the website, not the text editor.

In looking in the correct place for an existing bug report, I found this: http://groups.google.com/group/vim_dev/browse_thread/thread/4c137e64d2032441/b3993eaa89589619?lnk=gst&q=mouse#b3993eaa89589619

To summarize, it was an xterm limitation that has been lifted. However, Vim does not yet support columns longer than 223.

Original:
This seems to be a bug, as supported by comments made by redstreet. I filed a bug report:

https://sourceforge.net/tracker/?func=detail&aid=3389331&group_id=27891&atid=391887

bhinesley
  • 2,259
  • 2
  • 18
  • 15
  • Thank you for posting the bug report. This bug has been particularly annoying for me! – Jonathan Beebe Aug 11 '11 at 04:31
  • 2
    It's specifically a problem because I use the `tagbar` plugin, which opens up on the right-side of the window. I cannot click my mouse into it. – Jonathan Beebe Aug 11 '11 at 16:41
  • 3
    I use taglist, which I place on the left as a workaround. For tagbar, you can use `let g:tagbar_left = 1` in your vimrc. – bhinesley Aug 11 '11 at 18:28
4

A few years later, the bug still seems to be present. The solution I found is neovim: a modern refactor of vim. Among other features, this bug has been resolved.

I simply copied my .vimrc into .nvimrc, and my plugins just worked with nvim. Maybe I'll just keep using that.

Gyscos
  • 1,772
  • 17
  • 22