Simulate the X11 select buffer

[davidchisnall]

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).

[DHowett]

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]

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]

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]

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

The only exception is gnome-terminal. After long debates, the devs have decided (for consistency with other terminals) that, in gnome-terminal, Shift+Insert should paste from PRIMARY and Ctrl+Shift+V should paste from CLIPBOARD (although you have the options to customize some shortcuts).

[lindhe]

Seems similar to #1553