Repository navigation
Simulate the X11 select buffer #6250
Description
X11 provides multiple buffers (clipboards / pasteboards) with different semantics. The copy buffer is used for things that persist in the buffer. The select buffer shares some of the behaviour of copy-and-paste and some of drag-and-drop. Like drag-and-drop, the source is responsible for the storage of the buffer contents and the buffer goes away when the source changes this. Like copy-and-paste, copying (select) and pasting (middle click) are distinct operations that do not capture the mouse in the middle.
It is very useful to have access to both in a terminal. This works well in X11 terminals on Windows with VcXsrv:
- The select buffer (filled when you select text) is not copied to the Windows clipboard.
- The copy buffer (filled when you do a copy operation) is copied to the Windows clipboard.
- Changes to the Windows clipboard are mirrored into the X11 copy buffer.
- Middle click pastes from the select buffer if the select buffer contains anything, otherwise it pastes from the copy buffer.
This behaviour could be emulated by having a buffer that is internal to WT that is filled on select and used for a special paste option (which could be bound to middle-click once #1553 is resolved).
Activity
DHowett commentedon Jun 2, 2020
You know, I don't hate this idea. I'm worried, though, that it'll have to be opt-in for people who understand it (opt-in because Windows users may not immediately take to the idea, and will shout us down for having this "weird copy that doesn't go to the clipboard") and that uptake will therefore be relatively low...
davidchisnall commentedon Jun 2, 2020
I honk it would have to be an explicitly named option with something like X11SelectBufferCopy so that only people who like and want that behaviour will see it. Even on X11, people initially find it confusing, but once you’re used to it, it’s very useful.
TrentonAdams commentedon Sep 26, 2020
Another feature of this in Linux is that you can press ctrl-shift-v to paste the normal clipboard buffer, and ctrl-shift-c to copy to the normal clipboard buffer.
I feel these features are essential, if you're adopting a Linux system in Windows it should feel the same.
chenzhiwei commentedon Jul 13, 2021
More details on PRIMARY and CLIPBOARD: https://specifications.freedesktop.org/clipboards-spec/clipboards-latest.txt
Application authors should follow the following guidelines to get
correct behavior:
selecting but with no explicit copy should only set PRIMARY,
never CLIPBOARD
middle mouse button should paste PRIMARY, never CLIPBOARD
explicit cut/copy commands (i.e. menu items, toolbar buttons)
should always set CLIPBOARD to the currently-selected data (i.e.
conceptually copy PRIMARY to CLIPBOARD)
explicit cut/copy commands should always set both CLIPBOARD and
PRIMARY, even when copying doesn't involve a selection (e.g. a
"copy url" -option which explicitly copies an url without the
url being selected first)
explicit paste commands should paste CLIPBOARD, not PRIMARY
a selection becoming unselected should never unset PRIMARY
possibly contradicting the ICCCM, clients don't need to support
SECONDARY, though if anyone can figure out what it's good
for they should feel free to use it for that
cut buffers are evil; they only support ASCII, they don't
work with many clients, and they require data to be
copied to the X server. Therefore clients should avoid
using cut buffers and use only selections.
https://unix.stackexchange.com/a/178401
lindhe commentedon Jul 13, 2022
Seems similar to #1553