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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 04 Sep 2010 10:35:34 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: cyd@stupidchicken.com, 6956@debbugs.gnu.org
> 
> > 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.

Which means the first word goes to the clipboard and can be pasted in
other apps, while the extended selection goes to PRIMARY only and can
only be accessed by other apps via the mouse.  Is that correct?

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

I agree that this is confusing.  So maybe we should decide that a
"drag", for the purpose of mouse-drag-copy-region, does not include
extending the selection with whatever means.  Then, to pacify users
who want Emacs 23 behavior, we will need either (a) introduce a new
option, nil by default, which, when set non-nil, will copy selected
text to the kill ring, or (b) decide that this is a Windows-only
issue, and resolve it with a Windows-specific option with the same
effect as in (a) above.