improve PRIMARY buffer copy-paste behaviour, paste over

[Johannes Thrän]

On 3/6/20 12:47 PM, Thomas Kluyver wrote:
> One thing that might get broken: creating a selection with the keyboard (shift + arrow keys) and then middle clicking to paste it somewhere else. When you select with the keyboard, there's no mouse up event, and no other obvious event to mean a selection is 'finished'. Maybe this is an unusual pattern, but I bet there are some people who do it.
>
> Maybe the answer to that is just to say that PRIMARY is updated when either the mouse button is released, or the selection is changed with the keyboard.
>
> Thomas

Right, I don't want to interfere with text selection. So considering 
this and double/triple clicks, we could say

  - If text is marked with a mouse, the PRIMARY buffer is updated when 
the act of text selection is finished. Specifically, updates only happen 
on mouse button releases.

  - A text selection is replaced by the contents of the PRIMARY buffer 
when a middle click is registered within it.


The first point aligns with wayland's opinion on when the buffer update 
should happen. Its primary selection protocol states:
  "[...] In order to minimize calls in pointer-driven text selection, it 
should happen only once after the operation finished. [...]"

While I wrote this, I realized that waiting for the timeouts to run down 
in the context of double/triple clicks, which is required to only do the 
update once per selection operation, isn't good. Buffer updates after 
double click would get deferred by the timeout. Very quick people would 
notice and race conditions may happen.

This is why I wouldn't mention timeouts and live with this not being 
possible with triple and more click selections.
It'd be still very useful for middle click users.

The vast majority of clients I tried behave like described in point one 
(modulo triple click) already. And since the behaviour is encouraged by 
wayland also, the only real new requirement would be the second point.


Johannes