bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Djärv
Subject: bug#6956: 24.0.50; pasting mouse selection in other session pastes only first word
Date: Sat, 04 Sep 2010 10:35:34 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; sv-SE; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3



Eli Zaretskii skrev 2010-09-04 09.18:
Date: Wed, 01 Sep 2010 17:38:31 +0300
From: Eli Zaretskii<eliz@gnu.org>
Cc: 6956@debbugs.gnu.org

Ping!

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.

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.

        Jan D.


From: Chong Yidong<cyd@stupidchicken.com>
Cc: Drew Adams<drew.adams@oracle.com>, 6956@debbugs.gnu.org
Date: Tue, 31 Aug 2010 14:13:30 -0400

Eli Zaretskii<eliz@gnu.org>  writes:

Select some text (several words) with the mouse using double-click
mouse-1 on one word then mouse-3 on a later word in the text.

Does this constitute a "mouse drag"?  Can someone please tell what
happens on X with the recipe in this bug report?

Yes, this follows the rule that if the region is highlighted, the
primary selection is set.  On X, if you double-mouse-1 on a word and
extend the region with mouse-3, you can use mouse-2 to paste the entire
selection into another application.

The issue here is that mouse-drag-copy-region is advertised to copy to
the kill-ring regions which are highlighted by dragging the mouse.
But mouse-drag-copy-region only affects mouse-drag-region (via
mouse-drag-track), which is bound to mouse-1.  Mouse-3, OTOH, is bound
to mouse-save-then-kill, which is not affected at all by
mouse-drag-copy-region.

So when Drew double-clicks mouse-1, the highlighted first word is
indeed copied into the kill ring (and winds up in the clipboard), but
extending the region with mouse-3 doesn't copy the extended region.

What I think happens on X under mouse-drag-copy-region is that the
first word is copied into the clipboard, while the extended region is
copied to the PRIMARY selection by the code in command_loop_1 which
catches active regions.  Can you please verify this?

If my guess is correct, then I think this is a bug: we should copy the
whole region to the kill-ring when mouse-drag-copy-region is non-nil.
That is, if extending the region with mouse-3 as described in this
report indeed constitutes a "mouse drag".








reply via email to

[Prev in Thread] Current Thread [Next in Thread]