Don't clear clipboard when closing the app

[Tamriel]

I find it it annoying that my clipboard is cleared when I close the application where I copied something.
I thought that a clipboard manager, in this case the pre-installed cliphist, would solve it. But they do not.
Any ideas why?

[darkcity]

I don’t use cliphist so don’t know if it can be set to function as you require.

I use CopyQ which I have found very useful and doesn’t clear clipboard when exiting an application.

[Tamriel]

I tried CopyQ aswell, it does not help. Do you have to configure something special?

[winnie]

I use neither of the above clipboard managers (I’m on KDE.)

Is there any option for “sync with clipboard” or “prevent empty clipboard”?

[rene]

Are you per chance talking about “middlebutton paste”?

If so, please note that that’s the historic X Windows copy-paste method and it very explicitly works without a “clipboard” as an intermediary: middle-click paste transfers the at that time primary selection directly from source to destination, with nothing in between. I.e., there’s no way whatsoever it ever could work after the source application is closed.

If you weren’t taking about that historic middlebutton X Windows copy-paste method never mind, but given that I don’t seem to recognize the clearing of any clipboard in any context, seemed worthy of mention.

[EDIT] Oh lol, “sway” implies Wayland and, supposedly then, not historic X11 middlebutton paste (unless Wayland somehow emulates that; no idea). I failed to note the category from the frontpage of the forum.

[Kevin_Kofler]

Middle-click paste is also supported on Wayland these days, though not all applications/toolkits and compositors might support the extension. (Qt and GTK on the toolkit side, and KWin and GNOME Shell (mutter) on the compositor side definitely support it. I do not know whether Sway does.)

And at least on X11, the middle-click paste buffer (PRIMARY) is not all that different from the regular clipboard (CLIPBOARD) technically. (On Wayland, it is handled by a different protocol extension though.) Clipboard managers can retain both after the application has exited. (In fact, PRIMARY is normally invalid as soon as you unselect the text, but the clipboard manager can retain it, and if it does that, it will usually also keep retaining it after the application exists.) At least the KDE Plasma clipboard managers, both the clipboard plasmoid and the legacy Klipper application, can do that.

In any case, a clipboard manager should retain at least the explicitly copied clipboard after the application exits. I am unsure why that does not seem to be working for you on Sway, maybe the clipboard managers you tried do not support Wayland?

[rene]

As to the Wayland side I know quite literally nothing of its inner working; decided to leave the above reply up after noticing “Sway” only since I guess we might still be looking at some explicit emulation/compatibility thing if indeed OP is talking about middle-click select/paste.

But as to the X11 side I do believe I’ll want to disagree a bit with this:

@Kevin_Kofler

And at least on X11, the middle-click paste buffer (PRIMARY) is not all that different from the regular clipboard (CLIPBOARD) technically.

An as you say clipboard manager could do many things but the idea as to the normal primary selection is that no such thing as a clipboard let alone manager of such exists, historically and/or by default at least.

Looked into it some time ago when implementing an X11 “selection clear” utility (in a privacy context). As per e.g. https://www.x.org/docs/ICCCM/icccm.pdf (pg. 4) we have

Selections communicate between an owner and a requestor. The owner has the data representing the value of its selection, and the requestor receives it. A requestor wishing to obtain the value of a selection provides the following: [ … ]

If the selection is currently owned, the owner receives an event and is expected to do the following:
• Convert the contents of the selection to the requested data type
• Place this data in the named property on the named window
• Send the requestor an event to let it know the property is available

I.e., requestor (the pasted-into window) can even request a format conversion from owner, and in any case, it’s only at the time of the request, the middle-click paste, that the owner puts the selected data in a window property from where to then be collected.

Should owner cease to exist it would therefore then seem that certainly requestor is SoL and my Manjaro XFCE install would apparently agree: if you e.g. select something in Firefox it’s available for middle-click paste into a terminal but not after closing Firefox; that previously selected text would not seem to have made it onto any sort of clipboard indeed.

Now admittedly that ICCCM document is very old and crusty, and perhaps things have in some environments/circumstances changed in practice even under X11 – and once again no idea whatsoever about Wayland. But as to historic X behavior OP’s description would be expected which is what I triggered on. Probably useless here in Wayland spheres – certainly when not talking about middle-click select/paste. Will furthermore butt out.

[Tamriel]

The issue appears when pressing Ctrl+V, or doing righclick (then the paste menu entry is disabled).

[rene]

Okay, that would be “clipboard copy/paste” so certainly I’ll then butt out. Pardon; no idea.

[Kevin_Kofler]

@rene

Should owner cease to exist it would therefore then seem that certainly requestor is SoL and my Manjaro XFCE install would apparently agree: if you e.g. select something in Firefox it’s available for middle-click paste into a terminal but not after closing Firefox; that previously selected text would not seem to have made it onto any sort of clipboard indeed.

On my x86_64 desktop (admittedly not running Manjaro, but Fedora, but it should not matter – the only device on which I currently have Manjaro installed is my PinePhone) running KDE Plasma Desktop on X11 (default session changed from Plasma Wayland to Plasma X11) with the clipboard plasmoid, it does not behave like that, but as I described: I have just tested selecting some text in Falkon, then unselecting it, then middle-click-pasting it into KWrite. The text still gets pasted. Then I closed Falkon and tried middle-clicking again, it still worked.

@rene

I.e., requestor (the pasted-into window) can even request a format conversion from owner

In my experience, the clipboard plasmoid only manages plain text for PRIMARY selections, no formatting etc. That is how it handles the format conversion problem: It just always requests plain text.

[rene]

Just now quickly tried a Manjaro Cinnamon VM I have laying about and it when selecting in Vivaldi (which for some reason seems its default web-browser rather than Firefox) and pasting into its terminal (gnome-terminal) behaves as described for Manjaro XFCE, and as by me expected for “historic X”.

I agree it’s likely not a Manjaro issue as such and Manjaro KDE and possibly/probably Manjaro GNOME would likely do as you describe – but let us then in any case conclude that mileage may vary. I expect that anyone running Manjaro Sway would be immediately able to confirm/deny OP’s description at least but that’s seemingly neither of us both…

[ikim]

I also use Manjaro KDE Plasma and I find this thing so annoying. Every time I copy something from a browser or document, if I close that tab/browser or document, paste is not available anymore and I must open it back again, copy, paste, and then close.

[boredland]

to workaround this, we could provide a keybind for cliphist list | grep -m1 "" | cliphist decode.