bug#6956: 24.0.50; pasting mouse selection in other session pastes only first word

["Jan Djärv" <jan.h.d@swipnet.se>]

Eli Zaretskii skrev 2010-09-04 09.18:
>> Date: Wed, 01 Sep 2010 17:38:31 +0300
>> From: Eli Zaretskii<eliz@gnu.org>
>> Cc: 6956@debbugs.gnu.org
>
> Ping!
>
> I really need feedback for this, even if the feedback is that this is
> specific to MS-Windows and should therefore be fixed by Windows-specific
> changes.
>
> (FWIW, I think the problem is common to Windows and X alike.)

It is the same in X and NS, i.e. extending with mouse-3 does not put the 
region in the kill ring when mouse-drag-copy-region is t.

Just curious, what about the case when you start with shift-select on a few 
characters and then extend with mouse-3, is that a mouse drag to be copied 
when mouse-drag-copy-region is t?  Or double click word, shift select to 
extend, mouse-3 to extend and then shift select to extend, what goes into kill 
ring then?  The "mouse" in mouse-drag-copy-region makes these things difficult 
to figure out.

	Jan D.

>
>>> From: Chong Yidong<cyd@stupidchicken.com>
>>> Cc: Drew Adams<drew.adams@oracle.com>, 6956@debbugs.gnu.org
>>> Date: Tue, 31 Aug 2010 14:13:30 -0400
>>>
>>> Eli Zaretskii<eliz@gnu.org>  writes:
>>>
>>>>> Select some text (several words) with the mouse using double-click
>>>>> mouse-1 on one word then mouse-3 on a later word in the text.
>>>>
>>>> Does this constitute a "mouse drag"?  Can someone please tell what
>>>> happens on X with the recipe in this bug report?
>>>
>>> Yes, this follows the rule that if the region is highlighted, the
>>> primary selection is set.  On X, if you double-mouse-1 on a word and
>>> extend the region with mouse-3, you can use mouse-2 to paste the entire
>>> selection into another application.
>>
>> The issue here is that mouse-drag-copy-region is advertised to copy to
>> the kill-ring regions which are highlighted by dragging the mouse.
>> But mouse-drag-copy-region only affects mouse-drag-region (via
>> mouse-drag-track), which is bound to mouse-1.  Mouse-3, OTOH, is bound
>> to mouse-save-then-kill, which is not affected at all by
>> mouse-drag-copy-region.
>>
>> So when Drew double-clicks mouse-1, the highlighted first word is
>> indeed copied into the kill ring (and winds up in the clipboard), but
>> extending the region with mouse-3 doesn't copy the extended region.
>>
>> What I think happens on X under mouse-drag-copy-region is that the
>> first word is copied into the clipboard, while the extended region is
>> copied to the PRIMARY selection by the code in command_loop_1 which
>> catches active regions.  Can you please verify this?
>>
>> If my guess is correct, then I think this is a bug: we should copy the
>> whole region to the kill-ring when mouse-drag-copy-region is non-nil.
>> That is, if extending the region with mouse-3 as described in this
>> report indeed constitutes a "mouse drag".
>>
>
>