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?
1 Answer
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
primaryandclipboard.– muruCommented Jun 30, 2015 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?– jamessanCommented Jun 30, 2015 at 14:55
-
I doubt the former (been careful not to select any text), but about the latter, not at all sure.– muruCommented Jun 30, 2015 at 14:56
-
1In case anyone else is curious about this: command-line tools such as
xsel,xclip, etc. all "cheat" by forking and exiting the parent process. Commented Dec 17, 2015 at 14:49
*register at least (middle click), this is expected. As X does a request to the application with the last selection to get the contents.+?