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?

Community
  • 1
muru
  • 24,838
  • 8
  • 82
  • 143
  • @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
  • @lcd047 I read that. So how do I get it to «puts data into clipboard», as they say? – muru Jun 30 '15 at 14:26
  • @muru: The next comment to the same post outlines a possible workaround: create a daemon that when something tells X that it (something) has data for clipboard will obtain this data and in turn tell X that it (daemon) has this data. In this case when something exits, daemon will still be present and able to give this data. Search for «clipboard manager» in your repository, it should solve this issue. – lcd047 Jun 30 '15 at 14:28
  • @lcd047 "... without using an external utility" – muru Jun 30 '15 at 14:28
  • ... Then you're opposing to solving your own problem. :) Really, Vim can't do that on its own. – lcd047 Jun 30 '15 at 14:30
  • On a side note: ZyX used to be one of the main Vim developers (he seems more interested in neovim these days, although he still posts patches for Vim occasionally). – lcd047 Jun 30 '15 at 14:33
  • @lcd047 Why not? Other applications don't beat around the bush when I copy to clipboard (say, right-click and copy). Why Vim? Even selecting the text with a mouse and using the terminal's right-click & copy works as expected. – muru Jun 30 '15 at 14:33
  • How would I know? I didn't write that piece of code, sorry. I never even looked at it. – lcd047 Jun 30 '15 at 14:38
  • @lcd047 Code would a bit much, but documentation saying you can't would answer this question. – muru Jun 30 '15 at 14:39
  • Don't have any official reference either, sorry. – lcd047 Jun 30 '15 at 14:46
  • What about shift+insert ? did you try? –  Jul 01 '15 at 00:30

1 Answers1

13

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.

jamessan
  • 11,045
  • 2
  • 38
  • 53
  • 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