I do use the same vimrc on my local machine and on a remote machine to which I connect through SSH. I keep the vimrc synced between the machines for commodity. My issue starts when I set mouse=a, I really like using it since I do have a lot of stuff in listchars=.

On my local machine, to copy to the primary or clipboard buffers I let the mouse enter visual mode (selectmode=) and do "+y or "*y. That's all fine. On the remote machine I force mouse= to be empty and use the terminal's copy and paste functions.

If I enable mouse=a on the remote machine I can't copy and paste from it anymore because Vim takes over the mouse and the terminal never sees the selection. For now I'm lucky that the remote machine have Vim 7.4, and since I use Vim 8.0 on my local machine the following works:

if 800 >= v:version
  set mouse=a
  set mouse=

But it will break shortly since I'm about to update Vim on the remote machine.

I've tried connecting with ssh -X and ssh -Y to check if I can make the mouse work but without success. The selection works but the buffers (on the local machine) are not updated with the yank. The Vim process on the remote machine has a GUI compiled in and there is a Xorg running there, but the Vim process runs on that side of the connection and the Xorg buffers used are on that side. (Yes, this makes things more complicated.)

  • Is there a way to make Vim use the Xorg buffers on the connecting machine?
  • Or, is there a way (in VimScript) to test whether Vim is running in an SSH session as opposed to a local PTY?
  • Possibly helpful, though not asked: Some terminals override the application's mouse mode when shift is held (e.g. xterm, urxvt, gnome-terminal, PuTTy, etc) to allow you to use the terminal's clipboard/primary selection access, even when programs like vim want mouse reports.
    – John O'M.
    Mar 2, 2017 at 5:00

1 Answer 1


It works for me. I have ForwardX11 yes in my ~/.ssh/config file, which should have the same effect as running ssh with -X, and I started vim on the remote machine as vim -N -u NONE -i NONE to make sure my configuration wasn't affecting anything, then executed :set mouse=a. I entered some text into vim, then selected some of it with the mouse, then pasted it into gvim running on the local machine.

One way I test X11 forwarding over SSH is to run xclock & on the remote machine and verify that the clock appears on the local machine.

To test in a Vim script whether you are running over SSH, you can test for the presence of one of the variables ssh sets on the remote machine, e.g.,

if exists("$SSH_CONNECTION")
  • You're correct it works! I have hit two separate problems instead of the one I was thinking. (1) The remote machine is a Centos and they install Vim badly, gvim -v works. (2) ssh -X and ForwardX11 yes may result in permission problems, 'tis better to use ssh -Y and ForwardX11Trusted yes. Of course that assumes that you do trust the Xorg commands that come back through that connection. But in general, knowing that it works for someone made me dig in the right places, many thanks.
    – grochmal
    Mar 1, 2017 at 14:02
  • I am able to get mouse interaction working without X11 forwarding. set mouse=a and (unless you're on neovim) set ttymouse=xterm2. This "just works" without further modification over plain SSH, no forwarding. Mar 2, 2017 at 18:39
  • @MarcParadise - I'm pretty confident that you must do something clever with SSH and xterm apart from the vim settings. Things like xsel or xclip do not work without X11 forwarding, so SSH must be doing something clever (I suspect that you may have the forwarding defined in some system file 'cause ssh does not link against X11 libraries, but I may be wrong). I use urxvt with ttymouse=urxvt but tried xterm with ttymouse=xterm2 and was not successful :(
    – grochmal
    Mar 2, 2017 at 20:23
  • Ah, ok. I was talking about just the basics of being a able to use the mouse over ssh and have vim recognize it. I use tmux to manage my local clipboard - but yeah, no way around x11 tunnels if you want to have local clipboard access to remote content. Mar 2, 2017 at 21:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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