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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 05 Sep 2010 05:48:51 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: cyd@stupidchicken.com, 6956@debbugs.gnu.org, jan.h.d@swipnet.se, 
>  drew.adams@oracle.com
> 
> On 05/09/10 04:09, Eli Zaretskii wrote:
> 
> > What will this do in the use-cases described by Jan, where the
> > selection is extended by shift-arrows, before hitting mouse-3?
> 
> Jan D. wrote:
>  > 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?
> 
> When mouse-drag-copy-region is t, it will copy the new region at mouse-3 
> time

That's good, IMO.

> (it does not somehow make keyboard shift-selection itself do a 
> mouse-like copy...)

Should we make shift-selection act like a mouse drag?

> Now, maybe there is something more sensible that could be done, but what 
> is the best behaviour for mixed keyboard/mouse/keyboard/mouse selection 
> extension if you've just explicitly asked for mouse selections to do one 
> thing and keyboard selections another?

By default, shift-selected region should be placed in PRIMARY.  But
the question here is what should shift-selection do when
mouse-drag-copy-region is non-nil.  Should shift-selection behave like
dragging the mouse or not?