Persist Clipboard after Exiting Vim

159 views
Skip to first unread message

Michael Partridge

unread,
Aug 6, 2019, 4:59:37 AM8/6/19
to v...@vim.org
Is there a way to prevent the clipboard buffer from being cleared upon exit?

I am using the 'gvim' package on Archlinux. My terminal is suckless st.

The behavior I'm looking for is to use the system clipboard for yank, etc. procedures. I have achieved this by putting 'set clipboard=unnamedplus' in my config file. This puts yanked content into my system clipboard where I can Ctrl (+ Shift) + V the content anywhere else in my window-space, until I close Vim, at which point the buffer gets cleared.

I have noticed that paste 'p' still works between Vim files after closing, which makes it seem like the content is still in the buffer, but then why isn't it accessible via Ctrl (+ Shift) + V?

An example of use: take content from a Vim file and paste it into another application.


MCP

Tony Mechelynck

unread,
Aug 6, 2019, 5:26:09 AM8/6/19
to vim_use, v...@vim.org
See (for Linux) ":help x11-cut-buffer". As you said, another Vim can
still fetch the copied data from there. However not every non-Vim
application is even aware of the existence of X11 cut-buffers. For
many non-Vim applications, Edit→Paste (or Ctrl-V) uses the X11
clipboard (Vim's + register), <MiddleMouse> uses the selection (Vim's
* register), and that's that.

Using Ctrl+Shift+V in konsole uses konsole's pasting mechanism, a Vim
running in konsole sees nothing; xterm is not even aware of the X11
clipboard and uses only the <MiddleMouse> selection. Ctrl-V in Vim
itself is not used to paste, but either (a) in Normal mode, to start
Block-Visual, see ":help CTRL-V", or (b) in Insert and Command-line
mode, to insert a character literally, see ":help c_CTRL-V", ":help
i_CTRL-V" and ":help i_CTRL-V_digit".

Best regards,
Tony.

Eli the Bearded

unread,
Aug 6, 2019, 3:16:22 PM8/6/19
to vim_use
Tony Mechelynck <antoine.m...@gmail.com> wrote:
> Michael Partridge <mcp...@nau.edu> wrote:
>> Is there a way to prevent the clipboard buffer from being cleared upon
>> exit?

This shows a fundamental misunderstanding of the clipboard in X11. It is
not a place where stuff is stored, but a promise to supply content by a
running app. When the app has exited, it can no longer fullfil promises
and there is no clipboard to speak of.

The Apple Macintosh clipboard dates back to Macs being single process
systems and they worked around this problem by making the system itself
own the clipboard selection. It gave it persistence through application
launch and exits but also (particularly for large copies/cuts) imposed
a noticable resource drain on the system.

However that model of clipboard has become the one that most people use
when thinking about cut and paste, which makes the very different X11
one seem to behave weirdly.

>> The behavior I'm looking for is to use the system clipboard for yank,
>> etc. procedures. I have achieved this by putting 'set
>> clipboard=unnamedplus' in my config file. This puts yanked content into
>> my system clipboard where I can Ctrl (+ Shift) + V the content anywhere
>> else in my window-space, until I close Vim, at which point the buffer
>> gets cleared.

This is why there are tools like xclip that run background daemons to
hold on to a selection for fullfilling the content supply promise of
the clipboard.

>> I have noticed that paste 'p' still works between Vim files after
>> closing, which makes it seem like the content is still in the buffer,
>> but then why isn't it accessible via Ctrl (+ Shift) + V?

Vim, I expect, is storing it out of band, such as in ~/.viminfo .

> Using Ctrl+Shift+V in konsole uses konsole's pasting mechanism, a Vim
> running in konsole sees nothing; xterm is not even aware of the X11
> clipboard and uses only the <MiddleMouse> selection.

I don't know how st or konsole does it, but in xterm middle mouse and
shift-insert are fully configurable, as part of XTerm.vt100.translations.

Default translation for shift-insert:
Shift <KeyPress> Insert:insert-selection(SELECT, CUT_BUFFER0)

Deault translation for middle button paste:
~Ctrl ~Meta <Btn2Up>:insert-selection(SELECT, CUT_BUFFER0)

Where "~" means "without this modifier". In the xterm manpage, the
section on ACTIONS has documentation on the "functions" like
"insert-selection", but the documentation on the right hand side is
much harder to find. (And overall, XTerm.vt100.translations is a
cumbersome control method. It's a single unquoted string that needs
embeded newlines to be interpreted correctly, and can't support
inline comments.)

Elijah

John Little

unread,
Aug 6, 2019, 11:56:31 PM8/6/19
to vim_use
Eli the Bearded explained why the clipboard is "being cleared".

TL;DR install a clipboard manager.

The solution for most users on X is the DE runs a clipboard manager. I presume that your Arch install is bare bones and you haven't installed one yet. The Arch wiki entry for clipboard https://wiki.archlinux.org/index.php/Clipboard lists a few options. Such a manager watches the clipboard and copies it, so that when vim exits it is still available. "full featured" managers have things like a history, allowing some manipulation, and knowing about URLs.

If you are not on X,

Michael Partridge

unread,
Aug 15, 2019, 8:22:02 PM8/15/19
to vim...@googlegroups.com
Thank you Tony Mechelynck, Eli the Bearded, and John Little. This does stem from a fundamental misunderstanding of the X clipboard. Thank you for fortifying that understanding. I will proceed to install a clipboard manager.


MCP


--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/2025fe3c-49cb-445c-b8c6-00a237b00264%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages