copy/paste and the ICCCM

phrakture · 2005-06-07 15:12:57

Ok, so I spent some times looking through the ICCCM and other resources in an effort to better understand X's copy/paste mechanism, and to be able to explain it to others (as most people get really put off pasting to/from a terminal)

X has a number of "selection buffers":
PRIMARY
SECONDARY
CLIPBOARD
CUT_BUFFER0..CUT_BUFFER7

The cut buffers are no longer used, but still there because it's part of the X standard. If you delve into this stuff and are writing an app to take advantage of these things, do not use cut buffers, as they'll probably be removed in the near future.

That leaves us with 3 buffers: PRIMARY, SECONDARY, and CLIPBOARD. Secondary is almost never used, and it's best to ignore it, but I'll explain it none-the-less.
The CLIPBOARD buffer is your standard Windows/OSX style clipboard, and contents are only set there with an explicit "copy" or "cut" from an application.
The PRIMARY and SECONDARY buffers are used for visual selections. That is, whenever I highlight text, it is added to the PRIMARY buffer. The SECONDARY buffer is there to allow additional selections while preserving the PRIMARY selection (I think it's alt+button2 or something).

For most X based applications, the middle mouse button (button3) pastes the PRIMARY buffer, while an explicit "paste" from an application will paste the CLIPBOARD buffer. In firefox there is a setting to allow PRIMARY pasting (middlemouse.paste) - I enable it by default.

Ok, now let's work an example...
In an xterm I have irssi running. I also have firefox running. Someone posts a url to the IRC channel, that I'd like to look at. I highlight that text in the terminal, which sets the xterm as "selection owner" and pops the selected text into the PRIMARY buffer. I then switch to firefox... this is where most people mess up. I open another tab (ctrl+t) and middle click paste the link. People screw this up, because usually they will highlight the url to remove it before pasting. This fails, because highlighting causes firefox to become the "selection owner" and places *that* text into the PRIMARY buffer (this was the original reason for the SECONDARY buffer).

Now, most people have a problem with this PRIMARY/CLIPBOARD buffer thing (and I don't blame them). There *is* a workaround which will allow ctrl+c and ctrl+v (quasi-standard copy/paste) to work from a terminal.

*VT100.translations: #override
Ctrl<Key>C: select-cursor-start() select-cursor-end(CLIPBOARD,PRIMARY) n
Ctrl<Key>V: insert-selection(CLIPBOARD,PRIMARY)

NOTE: the above was done from memory, so I may be off slightly - I will correct it when I am at a machine which has a real terminal (not "cmd"). Note the order of the words at the end - that is the order it will try to use the buffers if there is a problem (or an empty buffer) with the previous one.

i3839 · 2005-06-07 20:23:22

I love the seperate buffers so that I can have something copied and in the select buffer at the same time, it's so convenient. Windows is near unuable for me without the selection buffer copy stuff and middle mousebutton pasting. (among a lot things...)

Dusty · 2005-06-07 21:01:09

I'm curious about this secondary buffer, which I've never heard of. Is it really possible to copy to and from it? again, this would solve the same problem, with the mozilla url, if you could copy from xterm into the secondary buffer, go highlight the text in location to the primary buffer, and then paste from the secondary buffer. BUT, how do you get text into and out of the secondary buffer? Is it application specific (sucks if it is...)?

Dusty

phrakture · 2005-06-07 21:21:51

Dusty wrote:

I'm curious about this secondary buffer, which I've never heard of. Is it really possible to copy to and from it? again, this would solve the same problem, with the mozilla url, if you could copy from xterm into the secondary buffer, go highlight the text in location to the primary buffer, and then paste from the secondary buffer. BUT, how do you get text into and out of the secondary buffer? Is it application specific (sucks if it is...)?
Dusty

the secondary buffer is overly complicated to use, so nothing uses it really (I don't think anything beyond xterm can use it) - basically, the run down is that you have one "selection owner" and two buffers... the application needs to do all this roundabout work to keep the selection owner the same after the secondary buffer is filled... it's wierd and I don't understand it... needless to say, you might be able to copy *into* it, but out of it is beyond that...

most people (including the FSF) just recommend against even trying to understand it...

if you want to see what can ensue when trying to understand it, read this:
http://lists.slug.org.au/archives/slug- … 00054.html

this is the guy who made xsel

phrakture · 2005-06-07 21:23:03

I've seen more elegant protocols in unlikely places. When blowflies fight
over a pile of elephant shit, their pecking order is a more elegant
protocol than ICCCM.

dust · 2005-06-08 04:13:10

Ahahaha, great quote phrakture. I've known about the primary buffer and its use for a bit, but I've never known about the seconday. Really cool, I love this community :3.

Arch Linux

#1 2005-06-07 15:12:57

copy/paste and the ICCCM

#2 2005-06-07 20:23:22

Re: copy/paste and the ICCCM

#3 2005-06-07 21:01:09

Re: copy/paste and the ICCCM

#4 2005-06-07 21:21:51

Re: copy/paste and the ICCCM

#5 2005-06-07 21:23:03

Re: copy/paste and the ICCCM

#6 2005-06-08 04:13:10

Re: copy/paste and the ICCCM

Board footer