5

We can copy to both the + and * registers, but this doesn't actually copy the content to X's memory (apparently). If you copy something from Vim using the * or + registers and quit Vim, poof! There's nothing left to paste. With other applications, this isn't the case - at least with the clipboard if not with primary. This StackOverflow post suggests using xsel or other external utilities. Is there a way to do this without using an external utility?

  • @Carpetsmoker, I meant X11's buffers, not Vim's registers, but this will do as well. – muru Jun 30 '15 at 14:04
  • AFAIK for the * register at least (middle click), this is expected. As X does a request to the application with the last selection to get the contents. – Martin Tournoij Jun 30 '15 at 14:04
  • @Carpetsmoker that seems to be the case. Any idea for +? – muru Jun 30 '15 at 14:05
  • Looks like it. See here and here... I believe the answer to this is using something like Parcellite, although I've found that these apps often come with their own problems and quircks... – Martin Tournoij Jun 30 '15 at 14:13
  • @muru The third comment to the second post you linked to explains what's going on: [The] process is the following: 1. You copy text. 2. Vim tells X that it has data for clipboard («tells that it has data», not «puts data into clipboard»). 3. You exit vim. 4. X now has no idea where he can get data for clipboard: clipboard is «cleared» – lcd047 Jun 30 '15 at 14:24
12

TL;DR: This isn't really possible without a clipboard manager (e.g. clipit, diodon, glipper, parcellite).

It's an explicit design choice of X to not store the data for the X selections, whether that's the PRIMARY (what Vim calls "*) or CLIPBOARD (what Vim calls "+) selection. When a user performs a copy in an application, the application just tells X Hey, I'm asserting ownership of the PRIMARY selection, just in case someone asks for the data., but that's it. It takes another application to actually request the data for X to bother shuttling it between the two applications.

This is likely due to the other design choice of explicitly being a client/server model to easily have X and applications running on different computers. In that setup, why would you ever want to copy the data across the network on a Copy if there may never be an actual Paste that uses the data?

Since you've ruled out using a different tool (commonly called a clipboard manager) to listen for the assertion, consume all the data, and then assert it now has ownership of the selection, you're almost out of luck.

There's one avenue left, called the cut buffers. These can hold data, but only a small, fixed amount of data and it must be ISO-8859-1 encoded. When Vim exits, if it still has an assertion on the PRIMARY selection, it will attempt to dump the contents into CUT_BUFFER0. Similarly, when you try to paste from the PRIMARY selection, many applications will, when no one is asserting ownership of the PRIMARY selection, fallback to looking for data in CUT_BUFFER0. If CUT_BUFFER0 does have data, then that will be pasted.

  • Then I must hunt for something else causing this. Or something's messed with my primary and clipboard. – muru Jun 30 '15 at 14:52
  • Are you sure you aren't causing another application to assert ownership of those in the interim? Are you sure the application you want to paste into will look at the cut buffers if nothing is asserting ownership of one of the selections? – jamessan Jun 30 '15 at 14:55
  • I doubt the former (been careful not to select any text), but about the latter, not at all sure. – muru Jun 30 '15 at 14:56
  • 1
    In case anyone else is curious about this: command-line tools such as xsel, xclip, etc. all "cheat" by forking and exiting the parent process. – Martin Tournoij Dec 17 '15 at 14:49

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.