Not possible to manipulate other cut buffers

[sersorrel]

Currently, xclip is hardcoded to only interact with cut buffer 0:

https://github.com/astrand/xclip/blob/8d10aec4784d5e02f5649ac4cb83d812bc4a03cf/xclip.c#L342-L345

It would be nice if there was a way to manipulate the other 7 cut buffers as well.

I have written a patch to add a -buffer argument, but there is no error checking, and probably other mistakes too.

[hackerb9]

This is an interesting idea and it is such a minor change that I think it wouldn't hurt, but I'm curious why you want the other cut buffers. The major problem I could see from having them is having to explain them in the man page. It is not helpful to people if the documentation gets too long or complicated.

Cut buffers can only store a limited amount of data (16MB on my machine) and they do not have target (data type) information. I find that having CLIPBOARD, PRIMARY, SECONDARY, and (if I need it) BUFFER0 is more than enough for me. What do you use them for?

By the way, I'm not sure if it makes more sense to have 'xclip -buffer 0' automatically imply '-selection buffer' or to change your syntax to 'xclip -selection buffer0' (using a digit as a suffix). Maybe both? Also, is there a reason you went with "-buffer" as the option name instead of "-cutbuffer" as xcutsel does?

Along the same lines, X actually allows any arbitrary string to be used to create the Atom that holds a selection. It isn't limited to PRIMARY, SECONDARY, and CLIPBOARD. Would letting xclip create selections with any string name meet the same need you have or would you still want cut buffers?

[sersorrel]

I was originally using the cut buffers for a tiny set of clipboard management keyboard shortcuts (basically just xcutsel without the GUI), though I only really used them once or twice.

The digit suffix (-sel buffer0) seems sensible – most of that patch was "by doing it this way I can just copy-paste from somewhere else as a hack to get it working" rather than putting any thought into how it should behave! I think I was using the cut buffers because they persist even if the originating application exits (which presumably selections with arbitrary names wouldn't), though mostly it was just the novelty of discovering something new about X and wanting to play with it.

Ultimately I don't think I have any need for the feature any more, and like you say, there's not much point bloating the program and its documentation to support an obsolete and little-used feature if nobody else wants it.

[hackerb9]

That's actually a good point about cut buffers living within the X server and not requiring a client program to daemonize for the clipboard to persist. I was thinking it might be useful to add arbitrary name support to xclip someday, so it would have been nice if doing so solved this problem as well. But, you are correct, selections with arbitrary names only last as long as the process which owns them is alive. So, not exactly a perfect replacement.

Having selections be an interprocess communication method instead of using cut buffers is a good idea on machines with very little RAM, but nowadays, even filling up all eight cut buffers to the max on my machine, only increases the X server footprint by 128MB. Hardly anything these days.

Concerning bloat: I don't think the program itself wouldn't be impacted much by supporting all the cut buffers. We'd just need to add one or two lines to handle atoi() of the last character of "-selection bufferX" and then use that integer instead of 0 in XStoreBuffer(). Oh, and there might need to be some boilerplate to make XrmParseCommand() happy, but that should be trivial.

Perhaps the man page can simply state that buffer0 through 7 are available for the obsolete cut buffers and leave it at that.

This bug does remind me that at some point I should add a section to the man page on Persistence and the X Clipboard. Perhaps when this bug gets resolved would be a good time to do that.