X selection

Posted Aug 3, 2023 19:04 UTC (Thu) by farnz (subscriber, #17727)
In reply to: X selection by jch
Parent article: Emacs 29.1 released

It's interesting to compare the (older) X11 mechanism to the Win32 clipboard mechanism in this regard.

In the X11 mechanism, the server provides the ability to own one or more selections; both cut and copy are "just" claiming ownership of a selection. Paste requires you to use the TARGETS atom to list possible formats, then choose one, then request a conversion to your preferred format; as an optimization, if you only support one possible format, you can ask for data in that format, and simply fail if the owner can't supply it. Once the data is converted to the right format by the owner, you can transfer it through the server.

Win32 is different in some significant ways:

Only one clipboard, rather than multiple selections.
Clipboard data formats are either "standard clipboard formats" (defined by the API), or "registered clipboard formats" (registered by name, multiple applications can register the same format.
There are built-in conversions between certain standard clipboard formats.
The default behaviour is to eagerly transmit the data to the server on cut/copy (via OpenClipboard/SetClipboardData/CloseClipboard), but an application can choose to merely indicate that it can supply the data in this format, and delay supplying it until it's requested.
You can send data to the server in multiple formats, which are expected to be different representations of the same data. Some of these can be delayed, others eager - for example, a word processor could eagerly supply the data as RTF (since that's what it has to hand), and offer delayed conversions to HTML and plain text. Or LibreOffice could eagerly supply in OpenDocument, with delayed conversions to RTF, HTML and plain text, but only where the data is small.
When the client requests the data, it asks the server to enumerate formats in preference order for the source. When it finds a format it's happy with, it asks for the data in that format. If it's a delayed offering, the server does IPC with the owner to get the conversion done, and then returns the data to the client as-if it were an eager offering.

It's worth noting that both mechanisms allow negotiating the format of a transfer; the primary difference is that the Win32 mechanism puts the data ownership in the server, and gives the owner no knowledge of when a paste happens (since it's implementation-defined when a delayed representation is requested by the server).