GNU bug report logs - #6956
24.0.50; pasting mouse selection in other session pastes only first word

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: David De La Harpe Golden <david <at> harpegolden.net>
Cc: cyd <at> stupidchicken.com, jan.h.d <at> swipnet.se, 6956 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: bug#6956: 24.0.50; pasting mouse selection in other session pastes only first word
Date: Sun, 05 Sep 2010 01:06:24 -0400

> Date: Sun, 05 Sep 2010 05:48:51 +0100
> From: David De La Harpe Golden <david <at> harpegolden.net>
> CC: cyd <at> stupidchicken.com, 6956 <at> debbugs.gnu.org, jan.h.d <at> swipnet.se, 
>  drew.adams <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.