Note that this is only applicable to Vim on *nix systems with an X server.
Let's reduce the test to this:
vim -u NONE
- insert a line of text
- yank it into either the plus or star register
- suspend (
- restore (
Result: the value that was yanked into one register is now also in the other register.
I think some inference is needed but the baseline facts are found in
:h x11-selection and
:h x11-cut-buffer. From the former:
X11 provides two basic types of global store, selections and cut-buffers,
which differ in one important aspect: selections are "owned" by an
application, and disappear when that application (e.g., Vim) exits, thus
losing the data, whereas cut-buffers, are stored within the X-server itself
and remain until written over or the X-server exits (e.g., upon logging out).
I think "exits" here should be "exits or is suspended". Why? Because if you change
the last two steps of the above test to...
- exit vim
vim -u NONE
The result will be exactly the same. Both registers will have the same value. So some mystery action is happening either way. What is it? From
Whenever Vim is about to become unavailable (either via exiting or becoming
suspended), and thus unable to respond to another application's selection
request, it writes the contents of any owned selection to CUT_BUFFER0. If the
"+ CLIPBOARD selection is owned by Vim, then this is written in preference,
otherwise if the "* PRIMARY selection is owned by Vim, then that is written.
We can infer that whatever value was yanked last, regardless of which register it was stored in, is the value that gets stored in the cut buffer before Vim is suspended or exited.
Finally, when starting or resuming from standby, Vim loads the plus and star registers with the contents of the clipboard/cut-buffer. No inference required here as it is easy to demonstrate: copy some text (from anywhere), start Vim as before,
:reg * + and there's the copied text.