[tom.horsley@ccur.com: Improving X selection?]

[tom.horsley@ccur.com: Improving X selection?]

[Richard Stallman]

Would people please think about this and talk with Tom Horsley about it?

------- Start of forwarded message -------
X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY 
	autolearn=failed version=3.1.0
Date: Fri, 12 Oct 2007 10:50:22 -0400
From: Tom Horsley <tom.horsley@ccur.com>
To: bug-gnu-emacs@gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Subject: Improving X selection?

Anyone who attempts to interact with a mix of older (xterm for
instance) and newer (gtk apps) with emacs while doing cut &
paste operations has undoubtedly noticed the persistent problem
of never winding up with the selection you actually want (now
that we have some folks using CLIPBOARD and others using
PRIMARY). Yes, you can set x-select-enable-clipboard, but all
that does is invert the set of incorrect text you get back.

I have just implemented a quick hack (definitely not suitable
for prime time) to the x-cut-buffer-or-selection-value
function. This hack observes when there is more than one "new"
selection and goes ahead and pushes the new ones it isn't
planning to return to the caller onto the kill ring.

Suddenly, life is wonderful! If I notice the last yank just
pasted in the wrong selection, all I need to do is run a
yank-pop and like magic the selection I actually wanted
replaces the nasty one I didn't want :-).

My question is this: If I were to change the possible return
values for the interprogram-paste-function so that it is
allowed to return a list of strings, and I modified all the
callers so they could expect a list of strings, and I made the
whole list get pushed on the kill ring, would such a change
likely be accepted? Or is an interface change like that too
radical? (Or do people even like the idea at all? :-).
------- End of forwarded message -------