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

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

[Drew Adams]

Dunno whether you prefer a new bug report for this or continuing the
saga within a previous bug report.  This is no longer about "No
primary selection", but picking up from the thread of bug #6689, for
background:
 
> > > I still want the ability to select text with the mouse 
> > > and yank it into the same or another Emacs session
> > > (even another session of another Emacs release -
> > > in either direction).
> > 
> > You can have it, if you customize mouse-drag-copy-region to 
> > t, like it was before the changes that broke mouse-2 on Windows.
> 
> Thanks for the info.  Hopefully, when all of the changes are 
> over and done with, and all of the default decisions made, 
> this and any other customizations needed to get back the 
> previous behavior will be documented together (e.g. in NEWS).
> 
> BTW, the doc string for that option doesn't say much about 
> what it does, at least to me.  And the option name doesn't 
> seem terrific either.
 
Have you actually tried it?  No, it does not work, for me at
least in GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of
2010-08-30 on 3249CTO.
 
Even if I set that option to t in both Emacs sessions (and even if both
sessions are of this latest build), the entire selection is not pasted.
 
For each session:
 
emacs -Q
 
M-x set-variable mouse-drag-copy-region RET t RET
 
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.
 
mouse-2 in the same session will correctly paste the complete selection.
But mouse-2 in the other session pastes only the first word of the
selection.
 
--

<user_grumble>
Not happy.  I sure wish this mouse/keyboard/copy/paste/kill/yank/ stuff
would converge on a fixed point and would be fixed once and for all, so
we could somehow get back the (superior) behavior we had (at least on
Windows) prior to Emacs 24.

For months now we've been promised that at a minimum users would be
able to easily get back the previous behavior.  But all we've seen for
those months is a steady stream of problems.  Admittedly some of those
problems are not directly related to each other - e.g. some are
applicable only to Windows or only to X or only to Mac or only to
xterms or only about the mouse or only about the keyboard or only
about copying or only about pasting or...

But they all seem to be related to the recent f.+ing with Emacs
selection in the name of conforming Emacs to X Window.  We keep
hearing about things having been fixed.  When will it end?

Sure, by trying Emacs 24 we accept that things will be imperfect
temporarily, but I don't recall something so basic being so
variously broken for so long before.   T E S T  before committing?

Even the prodigious, complex, and profound changes made by K. Handa
(and others) to add Unicode support in Emacs 23 did not introduce as
much perturbation to the development builds - far from it.  What's
going on in the current case that makes it so volatile?
</user_grumble>

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2010-08-30 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 31 Aug 2010 09:48:44 -0700
> Cc: 
> 
> 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?

> Not happy.  I sure wish this mouse/keyboard/copy/paste/kill/yank/ stuff
> would converge on a fixed point and would be fixed once and for all, so
> we could somehow get back the (superior) behavior we had (at least on
> Windows) prior to Emacs 24.
> 
> For months now we've been promised that at a minimum users would be
> able to easily get back the previous behavior.  But all we've seen for
> those months is a steady stream of problems.  Admittedly some of those
> problems are not directly related to each other - e.g. some are
> applicable only to Windows or only to X or only to Mac or only to
> xterms or only about the mouse or only about the keyboard or only
> about copying or only about pasting or...

I don't consider the current state of affairs as final on Windows in
this regard.  There's a couple of issues to discuss and then
implement, but I'm waiting for the dust to settle in the X builds,
before suggesting what I think should be done on Windows.

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

[Chong Yidong]

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.

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

[Drew Adams]

> Does this constitute a "mouse drag"?

AFAIK, yes.  mouse-3 does a "drag" officially.  Meaning that it extends (which
can also mean restricts) the selection.
 
> I don't consider the current state of affairs as final on Windows in
> this regard.  There's a couple of issues to discuss and then
> implement, but I'm waiting for the dust to settle in the X builds,
> before suggesting what I think should be done on Windows.

It is at least good to hear that the current state is not intended to be the
final state.  Thx.

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

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

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

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

[Jan Djärv]

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

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

[Eli Zaretskii]

> Date: Sat, 04 Sep 2010 10:35:34 +0200
> From: Jan Djärv <jan.h.d@swipnet.se>
> CC: cyd@stupidchicken.com, 6956@debbugs.gnu.org
> 
> > 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.

Which means the first word goes to the clipboard and can be pasted in
other apps, while the extended selection goes to PRIMARY only and can
only be accessed by other apps via the mouse.  Is that correct?

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

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

[Drew Adams]

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

Whatever you do, please do make it easy to restore the pre-24 behavior. That is
the EMACS behavior - the behavior that Emacs has long/always had (since it
introduced mouse support?).  It is not just the "Emacs 23 behavior".

FWIW, though I seldom use Emacs on X Window these days, I used it for well a
over a decade and I do not recall pasting with mouse-2 after selecting multiple
things (words, lines, whatever) using mouse-1 + mouse-3 (or using any other
mouse-selection method, for that matter) ever having done anything other than
paste the entire selection.  Including pasting between Emacs sessions.  I do not
believe this sane behavior is/was Windows-only.

IMO, when mouse-pasting after mouse-selecting, no one would ever want what is
pasted to be something different from what s?he had selected.  The meaning of
"drag" is irrelevant in this regard (though it might be relevant to some
function names or code comments).

What you select should be what gets pasted.  Period.  That has always been the
case, and it should always be the case, even if in your quest for progress (or
standards conformity) you relegate it to some non-default, optional behavior.

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

[Jan Djärv]

Eli Zaretskii skrev 2010-09-04 13.07:
>> Date: Sat, 04 Sep 2010 10:35:34 +0200
>> From: Jan Djärv<jan.h.d@swipnet.se>

>>
>> 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.
>
> Which means the first word goes to the clipboard and can be pasted in
> other apps, while the extended selection goes to PRIMARY only and can
> only be accessed by other apps via the mouse.  Is that correct?

Yes.

	Jan D.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <cyd@stupidchicken.com>, <6956@debbugs.gnu.org>
> Date: Sat, 4 Sep 2010 08:06:19 -0700
> 
> FWIW, though I seldom use Emacs on X Window these days, I used it for well a
> over a decade and I do not recall pasting with mouse-2 after selecting multiple
> things (words, lines, whatever) using mouse-1 + mouse-3 (or using any other
> mouse-selection method, for that matter) ever having done anything other than
> paste the entire selection.  Including pasting between Emacs sessions.  I do not
> believe this sane behavior is/was Windows-only.

It still works on X like you remember.  But it works because the
extended selection gets put into the PRIMARY selection, and mouse-2
pastes from there.  See Jan's response to my guess about this.

By contrast, on Windows, the (emulated) primary selection is not
accessible from other applications.

I'm awaiting Stefan or Chong to respond to my suggestions in this
thread.  If the decision is not to change anything on X, I will then
fix it for MS-Windows only, probably subject to a single option which
you will have to customize.

> IMO, when mouse-pasting after mouse-selecting, no one would ever want what is
> pasted to be something different from what s?he had selected.  The meaning of
> "drag" is irrelevant in this regard (though it might be relevant to some
> function names or code comments).

The problem is that on X, there are 2 different kinds of "pasting":
one from the clipboard, the other from PRIMARY.  The current
convention on X is that the mouse pastes from PRIMARY, while C-y
pastes from the clipboard.

"Drag" is relevant because Emacs puts the text you drag across into
the kill ring (when mouse-drag-copy-region is non-nil).  And anything
that goes to the kill ring automatically goes to the clipboard as
well.  By contrast, mouse-2 pastes only from PRIMARY.

And please, stop arguing with the principle.  Emacs operation on X wrt
selections and pasting has changed, and there's nothing you or me can
do about that, except making sure that there are options one can
customize to get the old behavior.  The default behavior on Windows
will need to follow the behavior on X, with some reasonable
compromises due to the fact that there's only the clipboard.  Again,
customizable options should exist to get you the old behavior on
Windows.  All I'm trying to do is get you what you want, and yet each
time I need to argue with you about this -- why?

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

[David De La Harpe Golden]

On 04/09/10 09:35, Jan Djärv wrote:
>
>
> 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.
>

Perhaps making mouse-save-then-kill respect mouse-drag-copy-region would 
be best.

Various people may or may not recall that I did originally propose a 
separate (and horribly named) customisation 
"mouse-save-then-kill-copy-region" [1] for this reason*.

I can't now really imagine a situation where you'd want 
mouse-drag-copy-region nil and the "mouse-save-then-kill-copy-region" t 
or vice versa, you'd always want either both nil or both t**.

[1] http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01018.html

(* I also munged in a ":double" setting, that made clipboard-interacting 
operations took one more click than usual - i.e. the first click only 
adjusted primary, but double and triple clicking acted like single and 
double clicking used to)

(** or with ":double" functionality , either both nil, m-d-c-r 
nil/m-s-t-k-c-r :double, or both t)

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

[Chong Yidong]

Eli Zaretskii <eliz@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.

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

[David De La Harpe Golden]

On 04/09/10 20:09, Chong Yidong wrote:

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

I had an initial stab (not bothering with "double" previously mentioned, 
guess there's no demand) that I was about to send, but then I realised 
my effort was inadequate, so just to note:

We _don't_ want a new kill ring entry for each new mouse-3 click in a 
different position for a given region activation, we want it to replace 
the front of kill-ring if it's extending a region that's already been 
saved to the kill ring previously in the same activation.

Testing emacs 22.3, it replaced, and as a comment in its (too different 
to use directly) source says:
  ;; We have already put the old region in the kill ring.
  ;; Replace it with the extended region.
  ;; (It would be annoying to make a separate entry.)

- having just tried a patch that didn't take pains to do that 
replacement, I can confirm it is annoying...


=========
Aside:  If someone were to make mouse-3 dragging extend an existing 
region some day*, of course you wouldn't want it copying to kill ring a 
zillion times.  Maybe mouse-3-drag-existing-region-adjustment could be 
added "cheaply" by reusing most of the existing mouse-drag.

* analogous with other-app Shift-Mouse-1 dragging, emacs of course 
having some popup font menu on Shift-Mouse-1 and using Mouse-3 for 
existing region adjustment where other apps tend to have a popup context 
menu on Mouse-3 and use Shift-Mouse-1 for existing region adjustment...

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

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 360 bytes --]

On 04/09/10 21:35, David De La Harpe Golden wrote:


> We _don't_ want a new kill ring entry for each new mouse-3 click in a
> different position for a given region activation, we want it to replace
> the front of kill-ring if it's extending a region that's already been
> saved to the kill ring previously in the same activation.
>

How about the attached?



[-- Attachment #2: mouse-save-then-kill-save-on-mdcr_r1.diff --]
[-- Type: text/x-patch, Size: 2771 bytes --]

=== modified file 'lisp/mouse.el'
--- lisp/mouse.el	2010-08-29 16:17:13 +0000
+++ lisp/mouse.el	2010-09-04 21:33:14 +0000
@@ -43,7 +43,11 @@
   :group 'mouse)
 
 (defcustom mouse-drag-copy-region nil
-  "If non-nil, mouse drag copies region to kill-ring."
+  "If non-nil, copy to kill-ring upon mouse adjustments of the region.
+
+For consistency this affects both actual mouse drag operations and
+`mouse-save-then-kill' (\\[mouse-save-then-kill]) operations that
+change the region."
   :type 'boolean
   :version "24.1"
   :group 'mouse)
@@ -1342,14 +1346,21 @@
 
 If the region is inactive, activate it temporarily.  Set mark at
 the original point, and move point to the position of CLICK.
+If `mouse-drag-copy-region' is non-nil, also save the region
+to the kill ring.
 
 If the region is already active, adjust it.  Normally, do this by
 moving point or mark, whichever is closer, to CLICK.  But if you
 have selected whole words or lines, move point or mark to the
 word or line boundary closest to CLICK instead.
+If `mouse-drag-copy-region' is non-nil, also save the region
+to the kill ring, replacing the previous kill corresponding
+to the already active region.
 
 If this command is called a second consecutive time with the same
-CLICK position, kill the region."
+CLICK position, kill the region (or delete it
+if `mouse-drag-copy-region' is non-nil - it will already
+have been saved to the kill ring by the previous click.)"
   (interactive "e")
   (mouse-minibuffer-check click)
   (let* ((posn     (event-start click))
@@ -1371,7 +1382,12 @@
      ((and (eq last-command 'mouse-save-then-kill)
 	   (eq click-pt mouse-save-then-kill-posn)
 	   (eq window (selected-window)))
-      (kill-region (mark t) (point))
+      (if mouse-drag-copy-region
+          ;; region already saved the previous click,
+          ;; don't make a duplicate entry, just delete
+          (delete-region (mark t) (point))
+        (kill-region (mark t) (point)))
+      (setq deactivate-mark t)
       (setq mouse-selection-click-count 0)
       (setq mouse-save-then-kill-posn nil))
 
@@ -1394,6 +1410,9 @@
 	  (goto-char (nth 1 range)))
 	(setq deactivate-mark nil)
 	(mouse-set-region-1)
+        (when mouse-drag-copy-region
+          ;; presumably region already copied to kill-ring once, so replace.
+          (kill-new (filter-buffer-substring (mark t) (point)) t))
 	;; Arrange for a repeated mouse-3 to kill the region.
 	(setq mouse-save-then-kill-posn click-pt)))
 
@@ -1405,6 +1424,8 @@
 	(if before-scroll (goto-char before-scroll)))
       (exchange-point-and-mark)
       (mouse-set-region-1)
+      (when mouse-drag-copy-region
+        (kill-new (filter-buffer-substring (mark t) (point))))
       (setq mouse-save-then-kill-posn click-pt)))))
 
 \f

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

[Chong Yidong]

Thanks, the patch looks generally OK, except for the following:

>  (defcustom mouse-drag-copy-region nil
> -  "If non-nil, mouse drag copies region to kill-ring."
> +  "If non-nil, copy to kill-ring upon mouse adjustments of the region.
> +
> +For consistency this affects both actual mouse drag operations and
> +`mouse-save-then-kill' (\\[mouse-save-then-kill]) operations that
> +change the region."

It is sufficient to say "This affects `mouse-save-then-kill'
(\\[mouse-save-then-kill]) in addition to mouse drags."

>  If the region is inactive, activate it temporarily.  Set mark at
>  the original point, and move point to the position of CLICK.
> +If `mouse-drag-copy-region' is non-nil, also save the region
> +to the kill ring.
>
>  If the region is already active, adjust it.  Normally, do this by
>  moving point or mark, whichever is closer, to CLICK.  But if you
>  have selected whole words or lines, move point or mark to the
>  word or line boundary closest to CLICK instead.
> +If `mouse-drag-copy-region' is non-nil, also save the region
> +to the kill ring, replacing the previous kill corresponding
> +to the already active region.

We don't need to explain what mouse-drag-copy-region does twice.
Just add a separate paragraph saying

  If `mouse-drag-copy-region' is non-nil, this command also saves the
  region to the kill ring, replacing the previous kill if it was also
  made with `mouse-save-then-kill'.

>  If this command is called a second consecutive time with the same
> -CLICK position, kill the region."
> +CLICK position, kill the region (or delete it
> +if `mouse-drag-copy-region' is non-nil - it will already
> +have been saved to the kill ring by the previous click.)"

Omit the part after the "-", it's not necessary.

> -      (kill-region (mark t) (point))
> +      (if mouse-drag-copy-region
> +          ;; region already saved the previous click,
> +          ;; don't make a duplicate entry, just delete
> +          (delete-region (mark t) (point))
> +        (kill-region (mark t) (point)))
> +      (setq deactivate-mark t)

What's the additional deactivate-mark for?

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

[Eli Zaretskii]

> Date: Sat, 04 Sep 2010 22:38:22 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: 6956@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, Jan Djärv
>  <jan.h.d@swipnet.se>, Drew Adams <drew.adams@oracle.com>
> 
> > We _don't_ want a new kill ring entry for each new mouse-3 click in a
> > different position for a given region activation, we want it to replace
> > the front of kill-ring if it's extending a region that's already been
> > saved to the kill ring previously in the same activation.
> >
> 
> How about the attached?

What will this do in the use-cases described by Jan, where the
selection is extended by shift-arrows, before hitting mouse-3?

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

[David De La Harpe Golden]

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.

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

[Eli Zaretskii]

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

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

[David De La Harpe Golden]

On 05/09/10 02:53, Chong Yidong wrote:

>> -      (kill-region (mark t) (point))
>> +      (if mouse-drag-copy-region
>> +          ;; region already saved the previous click,
>> +          ;; don't make a duplicate entry, just delete
>> +          (delete-region (mark t) (point))
>> +        (kill-region (mark t) (point)))
>> +      (setq deactivate-mark t)
>
> What's the additional deactivate-mark for?

Uh. Nothing, I think.

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

[David De La Harpe Golden]

[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]

On 05/09/10 02:53, Chong Yidong wrote:

> We don't need to explain what mouse-drag-copy-region does twice.
> Just add a separate paragraph saying
>
>    If `mouse-drag-copy-region' is non-nil, this command also saves the
>    region to the kill ring, replacing the previous kill if it was also
>    made with `mouse-save-then-kill'.
>

^^^ Strictly that's not true, it also replaces kills made by mouse-drag 
i.e. an already active region (otherwise you would drag select a region 
with mouse-1, then mouse-3 extend, and you'd get two kill ring entries).

Here's one with revised doc phrasing.

...I haven't tried making shift-selection respect 
"mouse"-"drag"-copy-region as yet, but that should be straightforward 
given similarity to the "select-active-regions => 'only" code path. 
(It's not like I'm personally going to use mouse-drag-copy-region => t 
in any case....)

The customization name would then be kind of misleading, but, well, it 
has company.   Effectively, mouse-drag-copy-region would "really" be 
something like the (hypothetical) "clipboard-active-regions => 'only" in 
end effect, though probably implemented by hitting the kill ring and 
thus (maybe) the os clipboard as a side effect, so maybe
"killring-active-regions => 'only" would be more accurate.








[-- Attachment #2: mouse-save-then-kill-save-on-mdcr_r2.diff --]
[-- Type: text/x-patch, Size: 2288 bytes --]

=== modified file 'lisp/mouse.el'
--- lisp/mouse.el	2010-08-29 16:17:13 +0000
+++ lisp/mouse.el	2010-09-05 14:07:38 +0000
@@ -43,7 +43,10 @@
   :group 'mouse)
 
 (defcustom mouse-drag-copy-region nil
-  "If non-nil, mouse drag copies region to kill-ring."
+  "If non-nil, copy to kill-ring upon mouse adjustments of the region.
+
+This affects `mouse-save-then-kill' (\\[mouse-save-then-kill]) in
+addition to mouse drags."
   :type 'boolean
   :version "24.1"
   :group 'mouse)
@@ -1348,8 +1351,13 @@
 have selected whole words or lines, move point or mark to the
 word or line boundary closest to CLICK instead.
 
+If `mouse-drag-copy-region' is non-nil, this command also saves the
+new region to the kill ring (replacing the previous kill if the
+previous region was just saved to the kill ring).
+
 If this command is called a second consecutive time with the same
-CLICK position, kill the region."
+CLICK position, kill the region (or delete it
+if `mouse-drag-copy-region' is non-nil)"
   (interactive "e")
   (mouse-minibuffer-check click)
   (let* ((posn     (event-start click))
@@ -1371,7 +1379,11 @@
      ((and (eq last-command 'mouse-save-then-kill)
 	   (eq click-pt mouse-save-then-kill-posn)
 	   (eq window (selected-window)))
-      (kill-region (mark t) (point))
+      (if mouse-drag-copy-region
+          ;; region already saved the previous click,
+          ;; don't make a duplicate entry, just delete
+          (delete-region (mark t) (point))
+        (kill-region (mark t) (point)))
       (setq mouse-selection-click-count 0)
       (setq mouse-save-then-kill-posn nil))
 
@@ -1394,6 +1406,9 @@
 	  (goto-char (nth 1 range)))
 	(setq deactivate-mark nil)
 	(mouse-set-region-1)
+        (when mouse-drag-copy-region
+          ;; presumably region already copied to kill-ring once, so replace.
+          (kill-new (filter-buffer-substring (mark t) (point)) t))
 	;; Arrange for a repeated mouse-3 to kill the region.
 	(setq mouse-save-then-kill-posn click-pt)))
 
@@ -1405,6 +1420,8 @@
 	(if before-scroll (goto-char before-scroll)))
       (exchange-point-and-mark)
       (mouse-set-region-1)
+      (when mouse-drag-copy-region
+        (kill-new (filter-buffer-substring (mark t) (point))))
       (setq mouse-save-then-kill-posn click-pt)))))
 
 \f

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 31 Aug 2010 09:48:44 -0700
> Cc: 
> 
> Dunno whether you prefer a new bug report for this or continuing the
> saga within a previous bug report.  This is no longer about "No
> primary selection", but picking up from the thread of bug #6689, for
> background:
>  
> > > > I still want the ability to select text with the mouse 
> > > > and yank it into the same or another Emacs session
> > > > (even another session of another Emacs release -
> > > > in either direction).
> > > 
> > > You can have it, if you customize mouse-drag-copy-region to 
> > > t, like it was before the changes that broke mouse-2 on Windows.
> > 
> > Thanks for the info.  Hopefully, when all of the changes are 
> > over and done with, and all of the default decisions made, 
> > this and any other customizations needed to get back the 
> > previous behavior will be documented together (e.g. in NEWS).
> > 
> > BTW, the doc string for that option doesn't say much about 
> > what it does, at least to me.  And the option name doesn't 
> > seem terrific either.
>  
> Have you actually tried it?  No, it does not work, for me at
> least in GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of
> 2010-08-30 on 3249CTO.
>  
> Even if I set that option to t in both Emacs sessions (and even if both
> sessions are of this latest build), the entire selection is not pasted.
>  
> For each session:
>  
> emacs -Q
>  
> M-x set-variable mouse-drag-copy-region RET t RET
>  
> 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.
>  
> mouse-2 in the same session will correctly paste the complete selection.
> But mouse-2 in the other session pastes only the first word of the
> selection.

Can this bug be closed now?  If not, what else needs to be fixed?

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

[Drew Adams]

> Can this bug be closed now?  If not, what else needs to be fixed?

Yes, that recipe works now, so you can close this one. Thx.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <6956@debbugs.gnu.org>
> Date: Thu, 16 Sep 2010 16:51:12 -0700
> 
> > Can this bug be closed now?  If not, what else needs to be fixed?
> 
> Yes, that recipe works now, so you can close this one. Thx.

Thanks, done.

If you have other annoyances to report as fallout from the selection
changes, please submit separate bug reports.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <6956-done@debbugs.gnu.org>
> Date: Fri, 17 Sep 2010 07:30:07 -0700
> 
> Actually, I'm not sure it is fixed. I cannot really test with the latest build I
> have, because of bug #. I get the impression that I still cannot paste the mouse
> selection between sessions running different Emacs versions (part of the bug
> report). You might try that, if you are able to use the latest Emacs version.

And the other Emacs version is what? 23.x?

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

[Drew Adams]

> > Actually, I'm not sure it is fixed. I cannot really test 
> > with the latest build I have, because of bug #7055.
> > I get the impression that I still cannot paste the mouse
> > selection between sessions running different Emacs versions 
> > (part of the bug report). You might try that, if you are able
> > to use the latest Emacs version.
> 
> And the other Emacs version is what? 23.x?

As I said, I cannot really test this in the latest build I have.

But it needs to work across all Emacs releases.
Try it with Emacs 20, 21, 22, 23.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <6956@debbugs.gnu.org>
> Date: Fri, 17 Sep 2010 09:20:20 -0700
> 
> > > Actually, I'm not sure it is fixed. I cannot really test 
> > > with the latest build I have, because of bug #7055.
> > > I get the impression that I still cannot paste the mouse
> > > selection between sessions running different Emacs versions 
> > > (part of the bug report). You might try that, if you are able
> > > to use the latest Emacs version.
> > 
> > And the other Emacs version is what? 23.x?
> 
> As I said, I cannot really test this in the latest build I have.

You said:

  I get the impression that I still cannot paste the mouse selection
  between sessions running different Emacs versions

I thought that meant you tried this between Emacs 24 and some other
version of Emacs, and saw some problem.  So I asked which other
version of Emacs was that.

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

[Drew Adams]

> > > > Actually, I'm not sure it is fixed. I cannot really test 
> > > > with the latest build I have, because of bug #7055.
> > > > I get the impression that I still cannot paste the mouse
> > > > selection between sessions running different Emacs versions 
> > > > (part of the bug report). You might try that, if you are able
> > > > to use the latest Emacs version.
> > > 
> > > And the other Emacs version is what? 23.x?
> > 
> > As I said, I cannot really test this in the latest build I have.
> 
> You said:
> 
>   I get the impression that I still cannot paste the mouse selection
>   between sessions running different Emacs versions
> 
> I thought that meant you tried this between Emacs 24 and some other
> version of Emacs, and saw some problem.  So I asked which other
> version of Emacs was that.

I now have a working Windows binary, built today.
I tried again - the same bug still exists.

As I said before (the recipe has not changed), starting with `emacs -Q':

Simply select text using mouse-1 + mouse-3 (or just double-click mouse-1) in an
Emacs 24 session and then use mouse-2 in an Emacs 20 (or 23 or whatever)
session. The text is not pasted.

In the opposite direction (select in Emacs 20/23, paste into Emacs 24) it works,
however.

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2010-09-20 on 3249CTO

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <6956@debbugs.gnu.org>
> Date: Mon, 20 Sep 2010 11:47:17 -0700
> 
> I now have a working Windows binary, built today.
> I tried again - the same bug still exists.
> 
> As I said before (the recipe has not changed), starting with `emacs -Q':
> 
> Simply select text using mouse-1 + mouse-3 (or just double-click mouse-1) in an
> Emacs 24 session and then use mouse-2 in an Emacs 20 (or 23 or whatever)
> session. The text is not pasted.
> 
> In the opposite direction (select in Emacs 20/23, paste into Emacs 24) it works,
> however.

I cannot reproduce this with yesterday's binary.  For me, it works in
both directions (tested with Emacs 23.2 as "the other" version).

So some other factor must be at work here.

You did remember to set mouse-drag-copy-region non-nil, right?

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

[Drew Adams]

> You did remember to set mouse-drag-copy-region non-nil, right?

No, sorry; I did not remember.
It works OK with that set to t.
Thx.

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

[Drew Adams]

> No, sorry; I did not remember.
> It works OK with that set to t.
> Thx.

However, `mouse-drag-copy-region' also copies the region to the kill ring.  That
is something different from what this bug is about.

What's needed is here is the ability to mouse-select in one Emacs session and
paste to another Emacs session, even if they are in different Emacs versions.
That needs to be possible (and it should also be the default behavior BTW)
without users also needing to pollute their kill ring with the selection.

In my personal case I might want to also copy to the kill ring, but that is
orthogonal.  This bug is about not being able to select with the mouse and paste
with the mouse - into a different session.

The bug is still a bug, I'm afraid.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <6956@debbugs.gnu.org>
> Date: Mon, 20 Sep 2010 13:43:35 -0700
> 
> However, `mouse-drag-copy-region' also copies the region to the kill
> ring.

Yes, this is because Emacs now copies to the clipboard only text that
is copied to the kill ring.

> What's needed is here is the ability to mouse-select in one Emacs session and
> paste to another Emacs session, even if they are in different Emacs versions.
> That needs to be possible (and it should also be the default behavior BTW)
> without users also needing to pollute their kill ring with the selection.

Was this possible in Emacs 23?  If so, how?

When I double-click mouse-1 in Emacs 23 to select a word, I can then
yank that word with C-y, and `(car kill-ring)' evaluates to that
word.  So I'm quite sure mouse-drag-copy-region non-nil does the same
as what you had in Emacs 23 and older.

> The bug is still a bug, I'm afraid.

No, it's a different bug.  This one was filed against my promise that
mouse-drag-copy-region will get you back the ability to get back the
behavior of Emacs 23 on Windows when you select text by
double-clicking mouse-1.  This now works exactly as it did in Emacs 23
(AFAICS), so any further complaints about mouse selections should be
in a separate bug.

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

[Drew Adams]

> > However, `mouse-drag-copy-region' also copies the region to the kill
> > ring.
> 
> Yes, this is because Emacs now copies to the clipboard only text that
> is copied to the kill ring.
> 
> Was this possible in Emacs 23?  If so, how?
> 
> When I double-click mouse-1 in Emacs 23 to select a word, I can then
> yank that word with C-y, and `(car kill-ring)' evaluates to that
> word.  So I'm quite sure mouse-drag-copy-region non-nil does the same
> as what you had in Emacs 23 and older.
>
> > The bug is still a bug, I'm afraid.
> 
> No, it's a different bug.  This one was filed against my promise that
> mouse-drag-copy-region will get you back the ability to get back the
> behavior of Emacs 23 on Windows when you select text by
> double-clicking mouse-1.  This now works exactly as it did in Emacs 23
> (AFAICS), so any further complaints about mouse selections should be
> in a separate bug.

No, it does not now work exactly as it did in Emacs 23.

Even setting `mouse-drag-copy-region' to nil in two sessions of `emacs -Q', one
for Emacs 22 and the other for Emacs 23 (for example), there is still no problem
selecting with the mouse and pasting into the other session. 

That is what this bug is about - it is not some other bug.

Here is the recipe, to be very clear:

1. emacs -Q ; in Emacs 22
2. M-x set-variable mouse-drag-copy-region nil RET
3. emacs -Q ; in Emacs 23
4. M-x set-variable mouse-drag-copy-region nil RET

5. Use mouse-1 and mouse-3 to select some text in one session and mouse-2 to
paste it into the other session.  Select + paste works with no problem in either
direction, and the kill ring is not affected.

Again:

> > What's needed is here is the ability to mouse-select in one 
> > Emacs session and paste to another Emacs session, even if
> > they are in different Emacs versions.
> > That needs to be possible (and it should also be the 
> > default behavior BTW) without users also needing to pollute
> > their kill ring with the selection.

Users need to be able to get back the pre-Emacs 24 behavior by customizing - no
ifs ands  or buts.  It is not enough that they might be able to do so when
`mouse-drag-copy-region' is non-nil or the moon is full.  They need to be able
to get this select+paste independently of whether mouse selection is copied to
the kill ring.

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <6956@debbugs.gnu.org>
> Date: Mon, 20 Sep 2010 14:41:07 -0700
> 
> No, it does not now work exactly as it did in Emacs 23.
> 
> Even setting `mouse-drag-copy-region' to nil in two sessions of `emacs -Q', one
> for Emacs 22 and the other for Emacs 23 (for example), there is still no problem
> selecting with the mouse and pasting into the other session. 

Emacs 24 did change the default behavior, so in Emacs 24, you _must_
set mouse-drag-copy-region non-nil to get the pre-Emacs 24 behavior.

If you can point out what is different in the behavior of Emacs 24
_after_ setting mouse-drag-copy-region wrt double-clicking mouse-1,
please do.  Otherwise, this bug is done.

> > > What's needed is here is the ability to mouse-select in one 
> > > Emacs session and paste to another Emacs session, even if
> > > they are in different Emacs versions.
> > > That needs to be possible (and it should also be the 
> > > default behavior BTW) without users also needing to pollute
> > > their kill ring with the selection.

It wasn't possible to do this in Emacs 23 without "polluting the kill
ring", AFAICS.  In Emacs 23, double-clicking mouse-1 would copy the
text to the kill ring even if mouse-drag-copy-region was nil.  If you
know otherwise, please show how to achieve that (in Emacs 23).

> Users need to be able to get back the pre-Emacs 24 behavior by customizing - no
> ifs ands  or buts.

They can -- by customizing mouse-drag-copy-region.  No ifs or buts.

> They need to be able to get this select+paste independently of
> whether mouse selection is copied to the kill ring.

Since this wasn't possible in Emacs 23, you are in effect asking for a
new feature.  The old behavior is completely restored by customizing
mouse-drag-copy-region; after that Emacs behaves on Windows in a way
that is 100% compatible with what it did in Emacs 23 and before.  If
you can show the difference in behavior, please do.  The fact that a
variable needs to be customized is not in itself a change in behavior.

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

[Drew Adams]

> > No, it does not now work exactly as it did in Emacs 23.
> > 
> > Even setting `mouse-drag-copy-region' to nil in two 
> > sessions of `emacs -Q', one for Emacs 22 and the other
> > for Emacs 23 (for example), there is still no problem
> > selecting with the mouse and pasting into the other session. 
> 
> Emacs 24 did change the default behavior, so in Emacs 24, you _must_
> set mouse-drag-copy-region non-nil to get the pre-Emacs 24 behavior.
> 
> If you can point out what is different in the behavior of Emacs 24
> _after_ setting mouse-drag-copy-region wrt double-clicking mouse-1,
> please do.  Otherwise, this bug is done.

A user in Emacs 20, 21, 22, 23 could have `mouse-drag-copy-region' nil, and thus
not have mouse selection touch the kill ring - in principle (even if not in
fact, because of a bug), and yet s?he was still able to select and paste using
the mouse - between sessions, including sessions with different Emacs versions.

That ability is lost. This is a regression wrt the advertised behavior for Emacs
22 through 23 (ever since that user option has existed).

Or if it is not lost, tell me how s?he can do that in Emacs 24.

> > > > What's needed is here is the ability to mouse-select in one 
> > > > Emacs session and paste to another Emacs session, even if
> > > > they are in different Emacs versions.
> > > > That needs to be possible (and it should also be the 
> > > > default behavior BTW) without users also needing to pollute
> > > > their kill ring with the selection.
> 
> It wasn't possible to do this in Emacs 23 without "polluting the kill
> ring", AFAICS. In Emacs 23, double-clicking mouse-1 would copy the
> text to the kill ring even if mouse-drag-copy-region was nil.  If you
> know otherwise, please show how to achieve that (in Emacs 23).

Yes. But what matters is not just "AFAICS" but what the product was _supposed_
to do, what `mouse-drag-copy-region' advertised that it did, even if it did not
actually do that on some (all?) platforms.

IOW, you seem to be just pointing out that there was an Emacs 22/23 bug here, in
that `mouse-drag-copy-region' polluted the kill ring even when it was nil.

We're not about to fix Emacs 22 or 23 bugs now, but we can at least make it work
as advertised/intended for Emacs 24.  I report the bug for Emacs 24, even if it
is also a bug for 22 and 23.

> > They need to be able to get this select+paste independently of
> > whether mouse selection is copied to the kill ring.
> 
> Since this wasn't possible in Emacs 23, you are in effect asking for a
> new feature.

That "new feature" was implicitly available before, even if it was prevented
from working for nil `mouse-drag-copy-region' because that option always acted
as non-nil.

> The old behavior is completely restored by customizing
> mouse-drag-copy-region; 

Not the intended, advertised behavior, but a buggy behavior.
`mouse-drag-copy-region' was a no-op option.  Now it works, but when it is nil
select+paste does not work between sessions with different Emacs versions.

> after that Emacs behaves on Windows in a way
> that is 100% compatible with what it did in Emacs 23 and before.  If
> you can show the difference in behavior, please do.  The fact that a
> variable needs to be customized is not in itself a change in behavior.

The problem is not needing to customize the behavior.  The problem is that the
nil value does not work wrt mouse select+paste.  The option was not created to
prevent select+paste between sessions (and only when those sessions are for
different versions!?). It was created only to choose whether the kill ring is
affected by mouse selection.  Mouse selection + paste should not depend on the
kill ring.

Users should be able to get the behavior that we claimed they could get in Emacs
22/23.  We never said that you could mouse-select + paste between sessions of
different versions only if the selection was copied to the kill ring. So let's
please find a way to let users do what was intended to be allowed in the past,
even if a bug prevented it back then.

The bug in the past was that `mouse-drag-copy-region' was a no-op.  That's fixed
now.  But a different bug now shows up, whether it was latently present before
or is new due to the change in selection in Emacs 24.  That new bug is the one I
reported: "pasting mouse selection in other session".

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

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <6956@debbugs.gnu.org>
> Date: Mon, 20 Sep 2010 15:24:22 -0700
> 
> A user in Emacs 20, 21, 22, 23 could have `mouse-drag-copy-region' nil, and thus
> not have mouse selection touch the kill ring - in principle (even if not in
> fact, because of a bug), and yet s?he was still able to select and paste using
> the mouse - between sessions, including sessions with different Emacs versions.
> 
> That ability is lost. This is a regression wrt the advertised behavior for Emacs
> 22 through 23 (ever since that user option has existed).

It isn't a regression on Windows, see below.  This thread was, at
least for me, only about w32.

> IOW, you seem to be just pointing out that there was an Emacs 22/23 bug here, in
> that `mouse-drag-copy-region' polluted the kill ring even when it was nil.

It's not a bug, it's how mouse selections work in Emacs: text gets to
the clipboard as a side effect of being put on the kill ring.  It has
always been like that, at least on Windows, in Emacs 23 and before, as
in Emacs 24.

> Not the intended, advertised behavior, but a buggy behavior.
> `mouse-drag-copy-region' was a no-op option.

That is a completely different issue.  mouse-drag-copy-region was not
a no-op only on X, where there's the PRIMARY selection in addition to
the clipboard.  Unless users of X are concerned about this change, I'm
not going to be.  (Neither do I understand why you should be, except
if you for some reason want to continue a pointless argument just for
the sake of it.)

> That new bug is the one I reported: "pasting mouse selection in
> other session".

That bug is solved, whether you like it or not, in exactly the way you
wanted: by having an option (that fortunately already existed) one
needs to customize.

And that is the last time I'm speaking on this bug.

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

[Drew Adams]

> > A user in Emacs 20, 21, 22, 23 could have 
> > `mouse-drag-copy-region' nil, and thus
> > not have mouse selection touch the kill ring - in principle 
> > (even if not in fact, because of a bug), and yet s?he was
> > still able to select and paste using the mouse - between
> > sessions, including sessions with different Emacs versions.

Question: was that bug only on Windows? Could users on X window set the var to
nil and mouse-select + pasted between sessions? If so, then this is a regression
not only in principle but in fact, i.e. wrt actual behavior, not only intended
behavior.

> > That ability is lost. This is a regression wrt the 
> > advertised behavior for Emacs 22 through 23 (ever since
> > that user option has existed).
> 
> It isn't a regression on Windows, see below.  This thread was, at
> least for me, only about w32.

Why not check what the behavior pre-Emacs 24 was on non-Windows? If users could
select+paste between sessions without affecting the kill ring before, and they
cannot now, then this is not only about w32.

> > IOW, you seem to be just pointing out that there was an 
> > Emacs 22/23 bug here, in that `mouse-drag-copy-region' polluted
> > the kill ring even when it was nil.
> 
> It's not a bug, it's how mouse selections work in Emacs: text gets to
> the clipboard as a side effect of being put on the kill ring.  It has
> always been like that, at least on Windows, in Emacs 23 and before, as
> in Emacs 24.

Forget about Windows. What's the behavior in X window? And what was it before
Emacs 24? Have users lost an ability to mouse-select + paste between sessions
without affecting the kill ring?

> > Not the intended, advertised behavior, but a buggy behavior.
> > `mouse-drag-copy-region' was a no-op option.
> 
> That is a completely different issue.  mouse-drag-copy-region was not
> a no-op only on X, where there's the PRIMARY selection in addition to
> the clipboard.  Unless users of X are concerned about this change, I'm
> not going to be.

If it is a bug on X then it needs to be fixed on X and Windows. Your attitude
seems to be: (a) you don't know or care about X, and (b) it never worked right
on Windows anyway, so (c) it's not a bug. The attitude should be: (a) it doesn't
work right on Windows, (b) if it used to work on X then if it doesn't work now
on X then there is an X bug, and (c) in that case it should also be fixed to
work on Windows.

> > That new bug is the one I reported: "pasting mouse selection in
> > other session".
> 
> That bug is solved, whether you like it or not, in exactly the way you
> wanted: by having an option (that fortunately already existed) one
> needs to customize.

The bug is not solved if it still doesn't work in the case where mouse selection
does not copy to the kill ring.

Again, I personally will probably let mouse selection copy to the kill ring, so
this is not about what I will use. And no, I don't care to argue about it just
for the heck of it. I think there might well be a loss of a user feature here.
On Windows there is not, in actuality, because it never worked properly. But on
X? Were users able to mouse-select and mouse-paste between sessions without
first copying to the kill ring?

More generally, if you can mouse-select+paste within an Emacs session without
affecting the kill ring, why shouldn't you be able to do that between sessions?
Seems natural, no?