mouse-yank-primary and bug #7699

mouse-yank-primary and bug #7699

[Eli Zaretskii]

I have a question for experts on X selections.

I think I can fix bug#7699 if I switch the order of calling
x-get-selection-value and x-get-selection in this snippet from
mouse-yank-primary:

  (let ((primary
	 (cond
	  ((fboundp 'x-get-selection-value) ; MS-DOS, MS-Windows and X.
	   (or (x-get-selection-value)
	       (x-get-selection 'PRIMARY)))

My question is: could switching the order do the wrong thing on X?  I
looked into x-get-selection-value and x-get-selection as they are
implemented on X, and they seem to do very similar things, but I don't
know enough to understand the semantics of the subtle differences.

If switching the order is not TRT on X, I could do that only for w32.

TIA

Re: mouse-yank-primary and bug #7699

[David De La Harpe Golden]

On 21/12/10 19:29, Eli Zaretskii wrote:
> I think I can fix bug#7699

Ho hum*.

> My question is: could switching the order do the wrong thing on X?

I expect so. See discussions under #6635, #6802.  x-get-selection-value 
(or the x-selection-value-internal it calls) is doing the relevant dance 
to get unicode.


*
I do remember a suggestion on my part to revert the rebinding of mouse-2 
but then introduce a customization that controls whether 
mouse-yank-at-click should either call mouse-yank-primary or do its thing.

That would mean a rebinding would be unnecessary to restore old 
behaviour, would just be purely customizations. Frankly I'm not clear 
that Drew (and to a lesser extent yourself) have  absorbed the fact 
rebinding of mouse-2 is presently necessary to restore old behaviour. 
Er. At least, I think it still is. Really I haven't quite caught up to 
the current trunk's state so I might be shooting my mouth off.

Anyway, mutating the new binding of mouse-2 until it acts like a creepy 
zombie version of the old binding seems ...a relatively awkward path to 
take.

RE: mouse-yank-primary and bug #7699

[Drew Adams]

> Frankly I'm not clear that Drew (and to a lesser extent
> yourself) have  absorbed the fact rebinding of mouse-2 is
> presently necessary to restore old behaviour.

Since you pointed to me...

What rebinding of mouse-2 are you referring to?

Eli has let it be known that setting `mouse-drag-copy-region' to t should
suffice to restore the traditional mouse-2 behavior on Windows.  And that's all
I'm using.

Please, let us know, if a different binding of `mouse-2' is needed also (or
instead).

This is the first I've heard of it, so I can hardly be accused of not having
absorbed it yet.  I cannot speak for Eli's alleged insufficient absorption.

> Er. At least, I think it still is.

We haven't absorbed it yet, but you have. Yet you're not sure.

> Really I haven't quite caught up to the current trunk's
> state so I might be shooting my mouth off.

Let us know.

Re: mouse-yank-primary and bug #7699

[David De La Harpe Golden]

On 22/12/10 01:38, Drew Adams wrote:

> What rebinding of mouse-2 are you referring to?

Rebind back to mouse-yank-at-click.

(global-set-key [mouse-2] 'mouse-yank-at-click)

 > is needed also

Yes, in addition to customizations

mouse-drag-copy-region => t
select-active-regions => nil

The old and new settings on w32 both have

x-select-enable-clipboard => t

so that doesn't need changing on w32 unless you've changed it.


 > Eli has let it be known that setting `mouse-drag-copy-region' to t
 > should suffice

IIRC there was a later and w32-specific change (very much against my 
advice at the time) involving mixing up primary and clipboard which he 
_may_ have thought obviated the need to revert the binding.

But, well, please do try the rebind and the customizations above 
together if you haven't tried them before.

RE: mouse-yank-primary and bug #7699

[Drew Adams]

> > What rebinding of mouse-2 are you referring to?
> 
> Rebind back to mouse-yank-at-click.
> (global-set-key [mouse-2] 'mouse-yank-at-click)
> 
> in addition to customizations
> mouse-drag-copy-region => t
> select-active-regions => nil
> 
>  > Eli has let it be known that setting `mouse-drag-copy-region' to t
>  > should suffice
> 
> IIRC there was a later and w32-specific change (very much against my 
> advice at the time) involving mixing up primary and clipboard 
> which he _may_ have thought obviated the need to revert the binding.
> 
> But, well, please do try the rebind and the customizations above 
> together if you haven't tried them before.

I appreciate the information and will save it.  But as Eli is the one working on
these things for Windows, I will take my cue from him.  AFAIK, this is still a
work in progress, and so far, setting `mouse-drag-copy-region' to t has DTRT.

Wrt setting `select-active-regions': That variable (new in Emacs 23) has very
poor documentation (see bug #7702), but from what I can tell from the doc it
should have _no effect at all_ on Emacs for Windows, because the latter does not
have a primary selection.

If that is not correct, then this too needs to be fixed in the doc, which
describes only its effect wrt the primary selection.

(And the doc string, as opposed to the Emacs manual treatment, is
incomprehensible, speaking of "the window selection", a concept defined
nowhere.)

Re: mouse-yank-primary and bug #7699

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 21 Dec 2010 20:18:37 -0800
> Cc: emacs-devel@gnu.org
> 
> Wrt setting `select-active-regions': That variable (new in Emacs 23) has very
> poor documentation (see bug #7702), but from what I can tell from the doc it
> should have _no effect at all_ on Emacs for Windows, because the latter does not
> have a primary selection.

Not entirely true: the Windows port emulates the primary selection
within the same Emacs session.  So customizing that option should make
active regions available for pasting with mouse-2 on Windows as well,
but only if you paste in the same Emacs session.

RE: mouse-yank-primary and bug #7699

[Drew Adams]

> > Wrt setting `select-active-regions': That variable (new in 
> > Emacs 23) has very poor documentation (see bug #7702), but
> > from what I can tell from the doc it should have _no
> > effect at all_ on Emacs for Windows, because the latter
> > does not have a primary selection.
> 
> Not entirely true: the Windows port emulates the primary selection
> within the same Emacs session.  So customizing that option should make
> active regions available for pasting with mouse-2 on Windows as well,
> but only if you paste in the same Emacs session.

That confirms what I said about the doc.  Nothing is said in the doc about this
emulation etc.

What this var does on a system where there is no primary selection is undefined
in the doc.  And the proviso about "same session" signifies a difference that
should also be pointed out as part of the description.

Re: mouse-yank-primary and bug #7699

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <david@harpegolden.net>, <emacs-devel@gnu.org>
> Date: Wed, 22 Dec 2010 07:11:38 -0800
> 
> And the proviso about "same session" signifies a difference that
> should also be pointed out as part of the description.

That could be in the manual, but I see no good way of documenting this
in the doc strings.  There's any number of functions and variables
related to selections; saying this in all of them seems a bad idea,
while saying just in some would not solve the problem.

RE: mouse-yank-primary and bug #7699

[Drew Adams]

> > And the proviso about "same session" signifies a difference that
> > should also be pointed out as part of the description.
> 
> That could be in the manual, but I see no good way of documenting this
> in the doc strings.  There's any number of functions and variables
> related to selections; saying this in all of them seems a bad idea,
> while saying just in some would not solve the problem.

I agree; the manual's the place.

The description of all of this stuff in the manual will need some work, once the
behavior is finalized.  It might not be easy to make it both readable and
comprehensive, but that's the challenge.

Re: mouse-yank-primary and bug #7699

[Eli Zaretskii]

> Date: Wed, 22 Dec 2010 01:05:52 +0000
> From: David De La Harpe Golden <david@harpegolden.net>
> 
> > My question is: could switching the order do the wrong thing on X?
> 
> I expect so. See discussions under #6635, #6802.  x-get-selection-value 
> (or the x-selection-value-internal it calls) is doing the relevant dance 
> to get unicode.

Thanks (both to you and Jan) for the pointers and the feedback.

What is still unclear to me (but not entirely relevant to the issue at
hand in bug #7699) is why do we call x-get-selection at all, when
x-get-selection-value returns nil?  What situation does this second
call take care of?  (I'm asking because my conclusion both from
reading the X implementation and from your responses, and also from
discussions archived in bugs #6635 and #6802, is that x-get-selection
is roughly a limited variant of x-get-selection-value, in that it
supports less data types.  But I'm probably still missing something.)

> Anyway, mutating the new binding of mouse-2 until it acts like a creepy 
> zombie version of the old binding seems ...a relatively awkward path to 
> take.

The bug report I'm talking about was not about restoring Emacs 23
behavior of mouse-2.  It is about having mouse-2 in Emacs 24 paste the
w32 emulated "primary selection", at least when the selection was made
in the same Emacs session (which is the limit of what we can currently
do on Windows).  I believe that on X, Drew's recipe works as expected,
i.e. the mouse-selected text is pasted, not the text in the clipboard.
I'm trying to do the same on Windows, without any rebinding of keys.

Re: mouse-yank-primary and bug #7699

[David De La Harpe Golden]

On 22/12/10 11:09, Eli Zaretskii wrote:

> What is still unclear to me (but not entirely relevant to the issue at
> hand in bug #7699) is why do we call x-get-selection at all, when
> x-get-selection-value returns nil?

(Bearing in mind that IMNHO mouse-yank-primary /shouldn't be/ calling 
the current w32 x-get-selection-value):

Remember that w32 x-get-selection-value follows the funny 
interprogram-paste-function protocol intended for kill-ring interactions 
that returns nil if the text has already been got. It _is_ w32's 
interprogram-paste-function after all!

So when you click mouse-2 on w32, you presently might get the clipboard, 
or you might get the emulated primary, depending on fairly complex 
(though deterministic) details of the interaction path leading up to the 
mouse-2 click. If you were to remove the call to x-get-selection on w32, 
you'd get the clipboard once (probably) and then nowt for subsequent 
clicks.

If you were to remove the call to x-get-selection-value that was 
inserted, on w32 you should get the emulated primary on all clicks if it 
is available, consistent with the function name "mouse-yank-primary", 
and bearing in mind it might or might not currently be being updated 
properly elsewhere on w32 (I haven't looked recently).

But wait - why does X11 now have and call a function called 
x-get-selection-value, then?  It was introduced because someone amended 
mouse-yank-primary to call the function called x-get-selection-value if 
it existed (which at the time it only did on w32/dos), then someone else 
decided to fix a bug by reusing the name and call site on x11.

2010-08-14  Eli Zaretskii  <eliz@gnu.org>

	* mouse.el (mouse-yank-primary): Fix mouse-2 on MS-Windows and
	MS-DOS.  (Bug#6689)

bzr diff -r101079..101080

2010-10-31  Jan Djärv  <jan.h.d@swipnet.se>

	* term/x-win.el (x-get-selection-value): New function that gets
	PRIMARY with type as specified in x-select-request-type. (Bug#6802).

  bzr diff -r102166..102167


So x11 x-get-selection-value is a function with the same name as one on 
w32 but very different behaviour, that always returns the primary value 
if available, handling encodings. It is is _not_ X11's 
interprogram-paste function (that's x-selection-value, "obviously"...).
So a fallback to x11 x-get-selection if x11 x-get-selection-value 
returns nothing on x11 is unnecessary but also fairly harmless in 
mouse-yank-primary.


> (I'm asking because my conclusion both from
> reading the X implementation and from your responses, and also from
> discussions archived in bugs #6635 and #6802, is that x-get-selection
> is roughly a limited variant of x-get-selection-value, in that it
> supports less data types.  But I'm probably still missing something.)
>

x-get-selection is the (relatively) lowlevel x11-selection-thingy 
getting function. Bearing in mind that I'm now talking about x11 
selection thingies in general which are used to implement all sorts of 
things, including the x11 clipboard and a bunch of other stuff, not just 
"the" [primary] selection.

i.e. x-get-selection is a more general lower-level x11-selection-thingy 
getting function. x-get-selection-value is a less general higher-level 
function that _only_ gets "the" [primary] selection (on x11! on w32 it's 
a quite different function bound to the same name!), but handling 
certain encoding issues.

You'll find that x11 x-get-selection-value calls x11 
x-selection-value-internal calls x11 x-get-selection.


* removal of the x-get-selection-value call from mouse-yank-primary 
would _now_ break x11, because of later changes mentioned above, but not 
in some hard-to-fix manner.

Re: mouse-yank-primary and bug #7699

[David De La Harpe Golden]

On 22/12/10 15:16, David De La Harpe Golden wrote:
>
> If you were to remove the call to x-get-selection-value that was
> inserted, on w32 you should get the emulated primary on all clicks if it
> is available, consistent with the function name "mouse-yank-primary",
> and bearing in mind it might or might not currently be being updated
> properly elsewhere on w32 (I haven't looked recently).


P.S. note that mouse-yank-at-click calls yank which calls current-kill 
which calls the interprogram-paste-function which is 
x-get-selection-value on w32.

Putting the call to w32 x-get-selection-value into mouse-yank-primary 
was pretty much where the "making it a zombie version of the old 
binding" remark was arising from.

Re: mouse-yank-primary and bug #7699

[Eli Zaretskii]

> Date: Wed, 22 Dec 2010 15:38:20 +0000
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: Djärv <jan.h.d@swipnet.se>, emacs-devel@gnu.org
> 
> Putting the call to w32 x-get-selection-value into mouse-yank-primary 
> was pretty much where the "making it a zombie version of the old 
> binding" remark was arising from.

No, it wasn't.  It was to fix a bug.

And yes, I know: the resulting behavior is not as clean on w32 as it
is on X, but given the lack of selections, I think that it's as good
as it gets.

Re: mouse-yank-primary and bug #7699

[David De La Harpe Golden]

On 22/12/10 19:23, Eli Zaretskii wrote:
 >> Date: Wed, 22 Dec 2010 15:38:20 +0000
 >> From: David De La Harpe Golden<david@harpegolden.net>
 >> CC: Djärv<jan.h.d@swipnet.se>, emacs-devel@gnu.org
 >>
 >> Putting the call to w32 x-get-selection-value into mouse-yank-primary
 >> was pretty much where the "making it a zombie version of the old
 >> binding" remark was arising from.
 >
 > No, it wasn't.  It was to fix a bug.
 >

It was a remark I just made. Whether you've unleashed the zombie plague 
to get your girlfriend back or to conquer Venus, you've still unleashed 
the zombie plague.

 > And yes, I know: the resulting behavior is not as clean on w32 as it
 > is on X, but given the lack of selections, I think that it's as good
 > as it gets.

Well, please don't assert that just changing mouse-drag-copy-region 
without changing the mouse-2 binding is actually sufficient to restore 
old behaviour on w32. If you did assert that, anyway (Miss, Drew said 
Eli said...).  If even after all my explanations you and/or Drew 
genuinely think it does restore the old behaviour (rather than causing a 
different behaviour that may or may not be an acceptable substitute), 
then well, we're failing to communicate and I just don't think there's 
much more I can do there on my end.

In any case, I'm now going to look at getting certain remaining 
selection issues on x11 sorted out (I've just proven to my satisfaction 
that at least one nasty one that was present back in the summer is still 
present now), they're rather more important to myself as an x11 emacs user.

Re: mouse-yank-primary and bug #7699

[Eli Zaretskii]

> Date: Wed, 22 Dec 2010 21:37:46 +0000
> From: David De La Harpe Golden <david@harpegolden.net>
> Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org
> 
> Well, please don't assert that just changing mouse-drag-copy-region 
> without changing the mouse-2 binding is actually sufficient to restore 
> old behaviour on w32. If you did assert that, anyway

I didn't.  It certainly does restore at least some aspects of the old
behavior, though.  Not sure how that is relevant to this discussion.

Re: mouse-yank-primary and bug #7699

[Eli Zaretskii]

> Date: Wed, 22 Dec 2010 15:16:59 +0000
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: emacs-devel@gnu.org, Djärv <jan.h.d@swipnet.se>
> 
> Remember that w32 x-get-selection-value follows the funny 
> interprogram-paste-function protocol intended for kill-ring interactions 
> that returns nil if the text has already been got. It _is_ w32's 
> interprogram-paste-function after all!
> 
> So when you click mouse-2 on w32, you presently might get the clipboard, 
> or you might get the emulated primary, depending on fairly complex 
> (though deterministic) details of the interaction path leading up to the 
> mouse-2 click. If you were to remove the call to x-get-selection on w32, 
> you'd get the clipboard once (probably) and then nowt for subsequent 
> clicks.
> 
> If you were to remove the call to x-get-selection-value that was 
> inserted, on w32 you should get the emulated primary on all clicks if it 
> is available, consistent with the function name "mouse-yank-primary", 
> and bearing in mind it might or might not currently be being updated 
> properly elsewhere on w32 (I haven't looked recently).

Thanks.  I know all that.  My question was about this pair of calls on
X, not about Windows.

> But wait - why does X11 now have and call a function called 
> x-get-selection-value, then?  It was introduced because someone amended 
> mouse-yank-primary to call the function called x-get-selection-value if 
> it existed (which at the time it only did on w32/dos), then someone else 
> decided to fix a bug by reusing the name and call site on x11.
> 
> 2010-08-14  Eli Zaretskii  <eliz@gnu.org>
> 
> 	* mouse.el (mouse-yank-primary): Fix mouse-2 on MS-Windows and
> 	MS-DOS.  (Bug#6689)
> 
> bzr diff -r101079..101080
> 
> 2010-10-31  Jan Djärv  <jan.h.d@swipnet.se>
> 
> 	* term/x-win.el (x-get-selection-value): New function that gets
> 	PRIMARY with type as specified in x-select-request-type. (Bug#6802).
> 
>   bzr diff -r102166..102167

I know this as well.  But I trust Jan that if he made that change, he
had a good reason for it.  I just don't know what was that reason.  My
guess is that he wanted to call x-selection-value-internal, instead of
x-get-selection, that's all.

> So x11 x-get-selection-value is a function with the same name as one on 
> w32 but very different behaviour, that always returns the primary value 
> if available, handling encodings. It is is _not_ X11's 
> interprogram-paste function (that's x-selection-value, "obviously"...).

Yes, I know.  The very different semantics of x-get-selection-value on
DOS and Windows is because in other situations this is what users
expect from code that calls x-get-selection-value.  Again, this is not
what I need help with.

Re: mouse-yank-primary and bug #7699

[David De La Harpe Golden]

On 22/12/10 19:17, Eli Zaretskii wrote:

> Thanks.  I know all that.  My question was about this pair of calls on
> X, not about Windows.
>

And hasn't that now been answered?

for x11:

sv = x11 x-get-selection-value
gs = x11 x-get-selection

sv alone :  ok
gs alone:  bad, though [1]
sv then gs:  okayish but pointless: gets to gs but gs will fail [2]
gs then sv:  bad, though [1]

[1] if you were to add a 'TEXT to the gs call, gs would get unicode as 
'TEXT is a pseudo data type that tries several.  However it would not 
respect x-select-request-type like sv does, which would still be 
arguably bad, though less so than just getting a 'STRING would be.

[2] except very rare races? thinking of a selection getting defined 
between the two calls in emacs, if context switched away after the first...

Re: mouse-yank-primary and bug #7699

[Eli Zaretskii]

> Date: Wed, 22 Dec 2010 22:10:25 +0000
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: emacs-devel@gnu.org, jan.h.d@swipnet.se
> 
> On 22/12/10 19:17, Eli Zaretskii wrote:
> 
> > Thanks.  I know all that.  My question was about this pair of calls on
> > X, not about Windows.
> >
> 
> And hasn't that now been answered?

Almost: I'd like Jan to tell whether my guess regarding the reason(s)
for his change was correct.

Thanks.

Re: mouse-yank-primary and bug #7699

[Jan D.]

Eli Zaretskii skrev 2010-12-23 05:03:
>> Date: Wed, 22 Dec 2010 22:10:25 +0000
>> From: David De La Harpe Golden<david@harpegolden.net>
>> CC: emacs-devel@gnu.org, jan.h.d@swipnet.se
>>
>> On 22/12/10 19:17, Eli Zaretskii wrote:
>>
>>> Thanks.  I know all that.  My question was about this pair of calls on
>>> X, not about Windows.
>>>
>>
>> And hasn't that now been answered?
>
> Almost: I'd like Jan to tell whether my guess regarding the reason(s)
> for his change was correct.
>

The reason was indeed to call x-selection-value-internal.  All this 
selection stuff is a bit messy now.  Ideally x-get-selection should use 
x-select-request-type and we could reduce the number of function that 
gets selection on X.  However, one would have to check all platforms and 
all uses of the current routines to do a good refactoring.

	Jan D.

Re: mouse-yank-primary and bug #7699

[Eli Zaretskii]

> Date: Thu, 23 Dec 2010 08:32:53 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: David De La Harpe Golden <david@harpegolden.net>, 
>  emacs-devel@gnu.org
> 
> The reason was indeed to call x-selection-value-internal.

Thanks!

> All this selection stuff is a bit messy now.

Yep.

> Ideally x-get-selection should use x-select-request-type and we
> could reduce the number of function that gets selection on X.
> However, one would have to check all platforms and all uses of the
> current routines to do a good refactoring.

One way forward would be for Someone™ to suggest the refactoring on
X, and then ask experts for other platforms to adapt the
platform-specific emulations to that.

Re: mouse-yank-primary and bug #7699

[Stefan Monnier]

>> Ideally x-get-selection should use x-select-request-type and we
>> could reduce the number of function that gets selection on X.
>> However, one would have to check all platforms and all uses of the
>> current routines to do a good refactoring.

> One way forward would be for Someone™ to suggest the refactoring on
> X, and then ask experts for other platforms to adapt the
> platform-specific emulations to that.

Indeed, and Emacs-24 is as good an opportunity as any to do such
a refactoring.


        Stefan

Re: mouse-yank-primary and bug #7699

[David De La Harpe Golden]

On 23/12/10 09:08, Eli Zaretskii wrote:
>> All this selection stuff is a bit messy now.
 >
>> Ideally x-get-selection should use x-select-request-type and we
>> could reduce the number of function that gets selection on X.
>> However, one would have to check all platforms and all uses of the
>> current routines to do a good refactoring.
>
> One way forward would be for Someone™ to suggest the refactoring on
> X,  and then ask experts for other platforms to adapt the
> platform-specific emulations to that.

That sorta presupposes continuation of the "make other platforms emulate 
x11" approach.  In this area, interposing another layer of 
indirection/abstraction might be more appropriate.

Actually we have half  a (slightly strange) one (interprogram-blah) 
that's used in some areas, but then other places use the x11y layer 
"below" directly.  So there's a "level mixed" api thing going on, and I 
reckon a fair bit of the messy is arising _because_ of that.

Jan just suggested expanding x-get-selection directly, but desire for 
its expansion may be arising mostly because it currently constitutes 
part of said level mixed api.  There shouldn't _be_ those direct calls 
to x-get-selection and x-set-selection in mouse.el and simple.el*, they 
should be hidden behind interprogram-get-selection-function and 
interpogram-set-selection-function (or something), like the way in the 
clipboard case they're hidden behind interprogram-cut-function and 
interprogram-paste-function.

(Alternatively existing stabs at cross platform abstraction should be 
ripped out and the exact x11 api used consistently (whether real or 
emulated on the various platforms) rather than the current muddle, but I 
suspect that's a rather less attractive option for most people)

P.S. there's the multitty can of worms to worry about. Sometimes it 
works out vaguely okay implicitly - the real x11 apis use the current 
frame's x11 display IIRC. Other times I suspect not so much.


(* despite my name being pretty directly attached to some of the 
changes, I don't view them as ideal. Some earlier attempts by myself to 
introduce such an abstraction layer were shot down, possibly because I 
didn't articulate well enough why it was desirable going on necessary)

Re: mouse-yank-primary and bug #7699

[Jan Djärv]

Eli Zaretskii skrev 2010-12-21 20.29:
> I have a question for experts on X selections.
>
> I think I can fix bug#7699 if I switch the order of calling
> x-get-selection-value and x-get-selection in this snippet from
> mouse-yank-primary:
>
>    (let ((primary
> 	 (cond
> 	  ((fboundp 'x-get-selection-value) ; MS-DOS, MS-Windows and X.
> 	   (or (x-get-selection-value)
> 	       (x-get-selection 'PRIMARY)))
>
> My question is: could switching the order do the wrong thing on X?  I
> looked into x-get-selection-value and x-get-selection as they are
> implemented on X, and they seem to do very similar things, but I don't
> know enough to understand the semantics of the subtle differences.
>
> If switching the order is not TRT on X, I could do that only for w32.
>

x-get-selection-value tries UTF8-STRING first, the COMPOUND_STRING and finally 
STRING (unless overridden by the user).  x-get-selection as called above only 
does STRING.  So for all cases when the selection isn't a latin-1 string, 
switching would most likely do the wrong thing.  There was a bug report about 
this (6802).  We can't rely on applications not sending STRING when the data 
isn't in latin-1.

	Jan D.