Selecting text never copies anything. Selections are just metadata that points back to the X client app that "owns" the selection and presumably also has the selected data. Selecting text simply sets the owner of the PRIMARY selection to the current X client, and "pasting" with middle click is asks the current owner of the PRIMARY selection to copy the selected data into the window targeted by the click.
From ICCCM[1]:
>> 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:
The name of the selection
The name of a property
A window
The atom representing the data type required
Optionally, some parameters for the request
>> 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
> If I want to keep the contents of my paste buffer, I have to force myself to remember not to highlight anything,
You're having this problem because you're using the PRIMARY selection when you should be using the CLIPBOARD selection which is more durable and intended[2] for data transfer and copy/paste-like semantics.
The Copy/Paste actions traditionally found in the "Edit" menu usually interact with the CLIPBOARD selection. This should be completely orthogonal to the middle-click feature and other interactions with the PRIMARY selection. You should be able to mix usage of both selections. Try this:
select text "foo"
use Copy from the Edit menu # CLIPBOARD now points to "foo"
select different text "bar" # PRIMARY now points to "bar"
move to an editable window
use Paste from the Edit menu # pastes "foo"
middle click the same window # pastes "bar"
Unfortunately, confusion about the X server using selections instead of a global buffer is not well explained.
The fact that you need a wall of text with multiple external sources to explain that I'm using copy and paste wrong is pretty conclusive supporting evidence in my favor.
If I have to read pages of documentation to understand how to do something that is utterly trivial and intuitive on every other major operating system, your approach is broken.
I'm just trying to help your "obliterated ... by a wayward mouse action" problem.
As I said at the end of the post, the actual behavior of some X Window System features are poorly explained and not obvious. The unexplained differences from the de fact standard behavior new users expect is as major usability problem. However...
> utterly trivial and intuitive on every other major operating system
It's worth remembering that when the standards document referenced in my previous [1] was originally written... a lot of those "major operating systems" didn't exist. In 1987, MS Windows was on version 1.0. I'm not sure it even supported any clipboard-like features. In that era, minimizing memory usage and network traffic were important, design goals.
> intuitive
"The only 'intuitive' interface is the nipple. After that, it's all learned." -- Bruce Ediger, on X interfaces
> I'm just trying to help your "obliterated ... by a wayward mouse action" problem.
That's fine and I do appreciate the information, but from the perspective of the overall discussion I think the point stands that the X approach to this is completely broken from a user perspective.
> It's worth remembering that when the standards document referenced in my previous [1] was originally written... a lot of those "major operating systems" didn't exist.
That's completely understandable, but we've had over thirty years to adapt. This argument is the same one that keeps Emacs greybeards defending M-k and M-y despite the fact that there hasn't been a Meta key on a single keyboard I've used in my 30 years of computing.
At some point you have to accept that the rest of the computing world has agreed upon a different standard than yours, and you either need to take steps to accommodate that or die.
That's not to say you can't try out new things while still abiding by existing standards (for instance, with advanced features like pastebuffer history), but that's completely different from clinging on to inferior historical approaches when everyone else has moved on.
Selecting text never copies anything. Selections are just metadata that points back to the X client app that "owns" the selection and presumably also has the selected data. Selecting text simply sets the owner of the PRIMARY selection to the current X client, and "pasting" with middle click is asks the current owner of the PRIMARY selection to copy the selected data into the window targeted by the click.
From ICCCM[1]:
>> 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: > If I want to keep the contents of my paste buffer, I have to force myself to remember not to highlight anything,You're having this problem because you're using the PRIMARY selection when you should be using the CLIPBOARD selection which is more durable and intended[2] for data transfer and copy/paste-like semantics.
The Copy/Paste actions traditionally found in the "Edit" menu usually interact with the CLIPBOARD selection. This should be completely orthogonal to the middle-click feature and other interactions with the PRIMARY selection. You should be able to mix usage of both selections. Try this:
Unfortunately, confusion about the X server using selections instead of a global buffer is not well explained.[1] https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM...
[2] https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM...