What I want in Vim with the mouse (and why I don't think I can have it)

September 4, 2016

I've recently been working on improving my vim environment, as part of getting better with it in general, and one of the things I've been doing has been turning on its 'mouse in xterm' support. This led me to a tweet:

I wish vim (in xterm) gave me better control over which mouse actions it did special things for and which ones acted just like xterm.

Since Twitter is not the best place to explain this, time to elaborate.

What I want is for vim to do things with the mouse, but for both middle mouse pasting and general selecting things to act like plain xterm. In any context where pasting things generally makes sense (so far, in insert mode and when I'm telling vim what to search for in a / or ?), the middle mouse button should paste the X selection. If I used vim intensely, I might be happy with its default behavior of the middle mouse button pasting in vim's unnamed register; since I don't, I found it infuriating. As far as mouse-based selection goes, I would like vim to handle double and triple-clicks more or less like xterm does and to export the resulting vim visual selection as the X selection.

(I'm aware that I can use shifted clicks in xterm to get much of this, but using Shift in vim and having to remember to do so is too annoying. I want plain mouse clicks to do the right thing.)

In reading through vim's help text, it seems that vim can at least come close to this with the right .vimrc settings. Unfortunately, there are two obstacles in practice. The first is that I need a version of vim compiled with the +xterm_clipboard feature. On all of the machines I use vim on, the normal vim program is not such a version. On some machines a suitable version is available as vimx; on others, it's not currently available at all and I'd either have to get additional packages installed or compile my own.

But the bigger problem is that this vim behavior requires having $DISPLAY available, in other words a live connection to my X server. Unfortunately, I often use vim in situations where I am sshing in to other machines, and despite improvements in Internet speed I do not want to have $DISPLAY set. Among other things, making a $DISPLAY available triggers all sorts of undesirable behavior in various other programs that I use. It is not worth trying to upend my environment this way in order to get the mouse working right in a mouse-aware vim.

It would be nice to be able to click things to move the cursor to them and to adjust the relative size of vim windows by grabbing the status bars, and probably other things I haven't found yet. But it's not worth making my select and paste life clearly worse, because I do a lot more select and paste inside vim than any other use of the mouse. So at least for now, I've stopped setting mouse to anything in my .vimrc.

(And I'm not currently interested in using a fully graphical vim. If I'm going to fire up a program that'll open up its own X window, so far it's going to be either sam or GNU Emacs, both of which I already have carefully configured for this purpose.)

PS: I'd be happy to be wrong about this, but as far as I can see the need for $DISPLAY is explicitly confirmed by vim's documentation. This is unfortunate, as modern versions of xterm (and possibly other terminal programs) offer access to the X selection through escape sequences, but it is what it is.

Sidebar: Why I care about having this be universal

I use vim in all sorts of different environments on all sorts of different machines, because it's my sysadmin editor. I want and in fact I need these various different vim environments to behave as much like each other as possible, so that I can develop a single set of vim reflexes that work everywhere (or almost everywhere). If some of my 'vim' environments behave one way (because I've set up a non-default version of vim and configured it) and some behave another way (because I haven't), I will be shooting myself in the foot.

It might work to start using graphical vim (ie, vim in its own window, not just running in an xterm), in the hopes that I would see graphical vim and vim-in-xterm as two sufficiently separate environments. But even that's a gamble and I'm not sure I want to find out how my reflexes react. It's simpler to just give up on smart mouse use in vim for now.

Comments on this page:

Does vim have anything similar to emacs' TRAMP mode?

By David Sowder at 2016-09-04 13:30:58:

If I'm not mistaken, no interactions with X can happen without $DISPLAY set. If I'm mistaken, I'd definitely like to learn.

By cks at 2016-09-04 17:47:47:

The simple answer is that xterm (and sufficiently compatible things) support passing through mouse events and so on via escape sequences; xterm calls this 'mouse tracking' and you can read the details about it in xterm's control sequences documentation. This works for anything running in an xterm, even if your program is running over ssh and doesn't have access to $DISPLAY, since all it involves is your program sending xterm some escape sequences and xterm sending escape sequences back. Vim uses this to support 'set mouse' even without $DISPLAY.

(This means that vim is not technically interacting with the X server directly. All the direct interaction is being done by the xterm process; it just does so at the behest of vim or whatever program is sending it those special escape sequences. This is not an important difference here.)

Xterm also supports getting and setting the X selection via escape sequences, but vim apparently doesn't use these. Instead it manipulates the X selection by talking directly to the X server, which means that this only works if it has $DISPLAY and so on.

By David Sowder at 2016-09-04 21:13:53:


So, I'll restate how I understand this so I'll know I got it:

xterm supports a sort of proxy of access to X selection and mouse details through an escape sequence protocol. vim uses that proxy for some things, but not all relevant things, so can't work as expected without direct X access.

One wonders if vim behaves this way intentionally and if not, how big the patch would be to change that behavior given a sufficiently capable programmer with enough knowledge of vim's code.

By cks at 2016-09-06 11:05:53:

Belatedly: I don't know how intentional this is (I haven't eg searched for filed vim issues talking about this), but I suspect that a patch to fix it would be fairly large and involved. Such a patch would have to add an entire separate mechanism of getting and setting the X selection using the xterm escape sequences, and properly recognize when this can be done, and so on.

Written on 04 September 2016.
« Why semantic versioning is not going to solve all our problems
An argparse limitation with nargs="*" and choices=... »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 4 00:55:27 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.