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: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Jan Djärv <jan.h.d <at> swipnet.se>, 6956 <at> debbugs.gnu.org
Subject: bug#6956: 24.0.50; pasting mouse selection in other session pastes only first word
Date: Sat, 04 Sep 2010 15:09:03 -0400

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

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

I'd rather not introduce another variable here.  I don't object to
allowing mouse-save-then-kill obey mouse-drag-copy-region (the emphasis
being on the "mouse" rather than the "drag"), provided the doc of
mouse-drag-copy-region is updated accordingly.

Any user who insists on changing mouse-drag-copy-region back to t can
deal with the inconsistency.

Previous Next

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