The Clipboard

Copy and paste feels like the simplest feature in the editor. On Windows it nearly is: OpenClipboard, SetClipboardData(CF_UNICODETEXT, hglobal) — the OS keeps a copy in a central store, and your process can exit without the data vanishing. macOS's NSPasteboard is the same central- store idea with a richer type system (writeObjects:, UTIs for types).

X11 did something completely different, and famously so: there is no clipboard. There is no central store at all. What X has is selections — a protocol for live negotiation between clients, standardized in the ICCCM. Understanding it will finally explain two Linux folklore facts: why middle-click paste exists, and why your copied text disappears when you close the app you copied it from.

Selections: copy is a claim, paste is a conversation

When you "copy" in an X11 app, no data moves anywhere. The app simply tells the server: I own the selection named CLIPBOARD now (that's xcb_set_selection_owner; the name is an atom — lesson 3's interned strings, back again). Whoever owned it before receives a SelectionClear event: you've been dethroned; release your buffered data. That's the entire copy operation — a claim, one previous owner notified. (There are several selections co-existing: CLIPBOARD for explicit Ctrl+C/Ctrl+V, PRIMARY for select-then-middle-click — the same protocol, different atom, which is how those two paste channels stay independent.)

Paste is where the data actually moves, and it's a four-step conversation between the requestor (the app being pasted into) and the owner (the app holding the copied data):

1. The requestor asks the server to deliver a SelectionRequest to the owner: "convert selection CLIPBOARD to target UTF8_STRING, and put the result in property P on my window W."
2. The owner receives the event, looks at the requested target, and — if it can — writes the converted bytes into property P on window W (properties are the server-side key-value storage from lesson 3, so the server briefly holds the data in transit).
3. The owner sends back a SelectionNotify: "done — look in property P." Refusal has a shape too: a SelectionNotify with property None (atom 0) means "I can't produce that target".
4. The requestor reads and deletes the property.

Before asking for text, well-behaved requestors first ask for the special target TARGETS: "what formats can you offer?" The owner answers with a list of atoms — UTF8_STRING, maybe text/html, maybe image/png from a screenshot tool. That's the negotiation that lets "paste" mean rich text between word processors but plain text into a terminal. Your editor's owner side supports exactly two targets: TARGETS itself, and UTF8_STRING.

Two consequences of this design, now explicable:

• Data dies with its owner. The owner is the store. Close the app and there is nobody left to answer SelectionRequests. (Clipboard- manager daemons fix this by watching for ownership changes and immediately requesting a copy for themselves — becoming a hidden second app that never exits.)
• Nothing transfers until paste. Copying a 100 MB selection costs nothing until someone asks for it — lazy, like the piece table.

One more protocol wrinkle you should recognize by name: server properties have practical size limits, so for large transfers the owner writes the property with type INCR instead of the requested target — "this will arrive in chunks" — and the two clients then ping-pong property writes and deletions until a zero-length write says done. We model the decision (small enough to send directly, or INCR?) without the chunk loop.

The seam stays honest through all of this: the editor core calls Platform::clipboard_write(text) and clipboard_read(). The Win32 backend implements those in six lines; the X11 backend runs this whole conversation — and the state machine at its heart is this lesson's first challenge, pure logic, no server needed.

The editing side: cut, copy, paste as document operations

Independent of transport, the three commands are selection-and-text algebra with firm conventions users rely on:

• Copy with a non-empty selection stores its text; the selection stays (you can copy, then keep typing to replace — er, no: copy does not collapse the selection; watch any editor). Copy with an empty selection is a no-op that must not clear the clipboard — nothing is more rage-inducing than losing a clipboard to a stray Ctrl+C.
• Cut = copy + delete selection + caret collapses where the text was.
• Paste replaces the selection (if any) with the clipboard, caret landing after the inserted text, selection collapsed. Pasting an empty clipboard is a no-op — it must not silently delete a selection.