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

Previous Next

Package: emacs;

Reported by: "Drew Adams" <drew.adams <at> oracle.com>

Date: Tue, 31 Aug 2010 16:48:02 UTC

Severity: normal

Found in version 24.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #56 received at 6956 <at> debbugs.gnu.org (full text, mbox):

From: David De La Harpe Golden <david <at> harpegolden.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, jan.h.d <at> swipnet.se, 6956 <at> debbugs.gnu.org,
	drew.adams <at> oracle.com
Subject: Re: bug#6956: 24.0.50; pasting mouse selection in other session pastes
	only first word
Date: Sun, 05 Sep 2010 05:48:51 +0100
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 (it does not somehow make keyboard shift-selection itself do a 
mouse-like copy...)

This is similar to older emacs behaviour for C-SPC active regions,
which would copy on mouse-3 extension of a C-SPC active region.

Jan D. wrote:
> Or double click word, shift select to extend, mouse-3 to extend and
> then shift select to extend, what goes into kill ring then?

This is more problematic when mouse-drag-copy-region is t, what it will 
do is copy the region at double-click time, not copy at shift-select 
extension time, then replace-copy at mouse-3 time, then the subsequent 
shift-select won't replace-copy the additionally altered region.

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?

I wouldn't bet there's a large overlap between people who like 
shift-selection and like mouse-drag-copy-region=>t in the first place, 
but possibly the "copying-ness" could be somewhat sticky, so once it 
copies owing to region change by mouse, it keeps replace-copying on each 
subsequent region extension whether by mouse or keyboard in the same 
activation? Yeesh.






This bug report was last modified 14 years and 329 days ago.

Previous Next


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