1

I am very used to using the double click of the mouse in a terminal to copy a word, such as a file name, then using the middle click of the mouse in a different terminal to paste.

However, this behavior does not seem to work under Fedora 24 when using vim. If I double click in a vim session it only selects one segment of the filename and it doesn't actually copy that piece to the clipboard because I can't paste it with the middle click.

Is there some setting in vim that causes this behavior (so I may disable it)? If I use \vi file copy-paste works normally but I lose syntax highlighting.

I'm using Fedora 24 and vim version 2:8.0.124-2.fc24. I have the following packages installed: vim-common, vim-enhanced, vim-filesystem, vim-minimal.

  • What is the output of :set mouse? in Vim? – muru Dec 26 '16 at 10:58
1

All of this is in the vim on-line help. But it's distributed across the doco for a number of variables and options, and there's not really an overarching guide to the whole thing.

Normal mode

Your terminal emulator has two modes. In its normal mode, it itself handles all mouse interaction. When you double-click, the terminal emulator decides what a word is, and does the highlighting of your selection. When you middle click, the terminal emulator obtains the selection from the X server and sends it to the terminal as if it were ordinary typed input.

If you run up minimal vim (which is the program with the name vi), or use :set mouse= in full vim, this is what you get. If you've ever tried pasting into vim using the middle mouse button you'll realize that vim is clearly not involved in the paste, because if you aren't in insert mode at the time the pasted text is treated as vim commands.

Mouse reporting mode

In its mouse reporting mode, however, your terminal emulator does not handle mouse actions itself. Rather it transmits the actions as if they ordinary typed input, encoded as special control sequences. An application program outputs other control sequences to turn mouse reporting mode on and off. (There are quite a lot of subtleties to this that relate to the fact that some of the mouse reporting protocols invented by the free software world were really bad. But that's beyond the scope of this answer.)

When you have mouse=a or mouse=h or similar set in vim, it changes the terminal mode on the fly between normal and mouse reporting modes, depending from the exact setting of mouse and what you are doing at the time. For example: When mouse=h, it turns mouse reporting on when you switch to a help screen, and back off when you switch away again.

When mouse reporting mode is on, it is vim itself that is deciding what a word is, that does the highlighting of your selection, and that communicates the selection to and from the X server. If you run up (full) vim with mouse=a or similar but without a way to know that there is a GUI available, by removing the DISPLAY environment variable from its environment, you'll find that whilst selection and paste work within vim, it cannot see the X selection and X applications cannot its selection. Indeed, there can be two selections on the screen concurrently, the one in an X application and the one in vim. (Minimal vim does not have the ability to talk to an X server in its code at all.)

Deciding what is a word

The rules for deciding what a word is differ. Your terminal emulator, depending from what emulator program it is, may or may not let you configure how it determines word boundaries. roxterm, Terminate, and LXTerminal all have a "select-by-word characters" setting in their preferences dialogues. Others simply hard-wire this.

Whichever is the case, it clearly thinks that a/b/c/d is all one word. So when the terminal emulator is in charge of dealing with mouse actions, this is what it sets as the selection in response to a double-click.

vim has its own set of quite independent settings, that are based upon what is considered to be a "keyword" and thus link into the regular expression matching and syntax colouring as well. Clearly whatever you have vim configured to understand about the current file (the iskeyword option being local to a buffer and adjustable by your selection of filetype) considers a/b/c/d to be multiple words separated by slashes. So this is what you get when vim has assumed charge of dealing with mouse actions.

Further reading

  • Thanks for the very helpful answer. The problem was, indeed, the mouse setting. I have set mouse= and now get the behavior I'm expecting. – Eric Sokolowsky Jan 2 '17 at 12:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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