[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mouse-yank-primary and bug #7699

From: David De La Harpe Golden
Subject: Re: mouse-yank-primary and bug #7699
Date: Wed, 22 Dec 2010 15:16:59 +0000
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101211 Icedove/3.0.11

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  <address@hidden>

        * 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  <address@hidden>

        * 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]