bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

> This behavior was never implemented.  If that is what you want, you
> are asking for a new feature, not reporting a bug, let alone a
> regression.

As I said: 

   ...you can call it an enhancement request...

   And until the requested enhancement is made there is a doc
   problem for `C-M-w', as it does not call out the fact that it
   doesn't append text selected with the mouse. AFAIK, there is no
   way to use `C-M-w' to cause a mouse selection to be appended
   to what was at the head of the kill-ring before that selection
   was made.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

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

This is a regression that was apparently introduced in Emacs 24.  Things

work properly (as documented and as expected) in Emacs 23.4 and prior,

but not in Emacs 24.5 or later.

 

1. emacs -Q

2. (setq mouse-drag-copy-region t) ; Mouse selection copies to kill-ring.

3. In *scratch*, select some text, e.g. "This buffer".

4. Use `M-w' to copy the selected text to the kill ring.

5. With the mouse, select some other text, e.g. "visit that file".

6. Use `C-M-w M-w', to append the second selection to the first as the

   last kill.  The kill should thus be "This buffervisit that file".

7. `C-y' to yank the last kill.

 

The text yanked should be "This buffervisit that file".  Instead, it is

"visit that filevisit that file".  That is, the second selection is

added to the kill ring and appended to itself.

 

It makes no difference how the first selection (step #3) is made: with

the mouse or not.  It should also not make a difference how the second

selection (#5) is made.  And there certainly is no use case for doubling

the text from the second selection (#5) for the yank.

 

In GNU Emacs 26.1 (build 1, x86_64-w64-mingw32)

of 2018-05-30

Repository revision: 07f8f9bc5a51f5aa94eb099f3e15fbe0c20ea1ea

Windowing system distributor `Microsoft Corp.', version 10.0.16299

Configured using:

`configure --without-dbus --host=x86_64-w64-mingw32

--without-compress-install 'CFLAGS=-O2 -static -g3''

 

[-- Attachment #2: Type: text/html, Size: 4604 bytes --]

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Eli Zaretskii]

> Date: Sun, 16 Sep 2018 14:29:25 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> This is a regression that was apparently introduced in Emacs 24.  Things
> work properly (as documented and as expected) in Emacs 23.4 and prior,
> but not in Emacs 24.5 or later.
>  
> 1. emacs -Q
> 2. (setq mouse-drag-copy-region t) ; Mouse selection copies to kill-ring.
> 3. In *scratch*, select some text, e.g. "This buffer".
> 4. Use `M-w' to copy the selected text to the kill ring.
> 5. With the mouse, select some other text, e.g. "visit that file".
> 6. Use `C-M-w M-w', to append the second selection to the first as the
>    last kill.  The kill should thus be "This buffervisit that file".
> 7. `C-y' to yank the last kill.
>  
> The text yanked should be "This buffervisit that file".  Instead, it is
> "visit that filevisit that file".  That is, the second selection is
> added to the kill ring and appended to itself.

I see something almost opposite:

 . in Emacs 23.4, the above recipe produces the "wrong" behavior,
   unless I set mouse-drag-copy-region to nil (it is t by default)

 . in Emacs 24 and later, mouse-drag-copy-region is nil by default, so
   the recipe works in "emacs -Q" without any customizations, but if I
   set mouse-drag-copy-region to t, I get the old "wrong" Emacs 23
   behavior

So I wonder what is going on with your system that you seem to see
such strikingly different results.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

> This should not have been retitled to be about "mouse kills", I think.
> It's only about non-nil `mouse-drag-copy-region' - its implicit copying
> to the kill ring. It's not about mouse kills.

And if really want to retitle it based on the discussion then it should say
something like this:

"Be able to mouse-select noncontiguous bits of text and get
their concatenation at the head of `kill-ring'"

or perhaps

"Be able to append mouse selections at the head of `kill-ring'"

I think that `C-M-w' should let you do that. But AFAIK there is no way
to do it, whether using `C-M-w' or anything else.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Eli Zaretskii]

> Date: Thu, 20 Sep 2018 08:16:18 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 32747@debbugs.gnu.org
> 
> > This should not have been retitled to be about "mouse kills", I think.
> > It's only about non-nil `mouse-drag-copy-region' - its implicit copying
> > to the kill ring. It's not about mouse kills.
> 
> And if really want to retitle it based on the discussion then it should say
> something like this:
> 
> "Be able to mouse-select noncontiguous bits of text and get
> their concatenation at the head of `kill-ring'"
> 
> or perhaps
> 
> "Be able to append mouse selections at the head of `kill-ring'"
> 
> I think that `C-M-w' should let you do that. But AFAIK there is no way
> to do it, whether using `C-M-w' or anything else.

I don't understand why you address this to me although it's clear that
I didn't retitle this bug.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

This should not have been retitled to be about "mouse kills", I think.
It's only about non-nil `mouse-drag-copy-region' - its implicit copying
to the kill ring. It's not about mouse kills.

bug#32747: Be able to append mouse selections at the head of `kill-ring' (e.g, with C-M-w)

[Lars Ingebrigtsen]

Noam Postavsky <npostavs@gmail.com> writes:

> retitle 32747 C-M-w (append-next-kill) doesn't work with mouse kills

And this seems to be because `C-M-w' works by setting `last-command' to
`kill-region' to signal that the next `copy-region-as-kill' should
append.  However, when dragging a region, `last-command' ends up being
nil by the time we reach `copy-region-as-kill' -- presumably because we
clear it somewhere in the mouse handling?

Anybody have any ideas how to fix this, if we want to fix this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32747: Be able to append mouse selections at the head of `kill-ring' (e.g, with C-M-w)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And this seems to be because `C-M-w' works by setting `last-command' to
> `kill-region' to signal that the next `copy-region-as-kill' should
> append.  However, when dragging a region, `last-command' ends up being
> nil by the time we reach `copy-region-as-kill' -- presumably because we
> clear it somewhere in the mouse handling?
>
> Anybody have any ideas how to fix this, if we want to fix this?

The following patch fixes this, but it's not clear that we want to do
this.

`C-w C-d' (kill-region + kill-word) will make the second kill append
to the first, while similar commands like `M-w C-d' don't.  So the
mouse.el code has:

	 ;; Ignore
	 ;; `last-command' so we don't append to a preceding kill.

Because we don't want `C-w <drag-mouse-1>' to append to that `C-w',
apparently.

But -- if you do something like `C-d M-w', then that `M-w' is morally
equivalent to the <drag-mouse-1> (i.e., we're putting more stuff onto
the kill ring without killing text).

So why is `C-w <drag-mouse-1>' different here?  The patch makes them
behave the same way.

If we don't want that, we have to come up with a whole nother way to
implement `C-M-w', because it just sets last-command to `kill-region'.

Opinions?

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 4b5f6ed223..5913992e44 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -1396,7 +1396,8 @@ mouse-set-region
 	 ;; Don't set this-command to `kill-region', so a following
 	 ;; C-w won't double the text in the kill ring.  Ignore
 	 ;; `last-command' so we don't append to a preceding kill.
-	 (let (this-command last-command deactivate-mark)
+	 (let ((last-command last-command)
+               this-command deactivate-mark)
 	   (copy-region-as-kill beg end)))
     (if (numberp beg) (goto-char beg))
     ;; On a text terminal, bounce the cursor.
@@ -1499,6 +1500,7 @@ mouse-drag-region
       (mouse-drag-and-drop-region start-event)
     ;; Give temporary modes such as isearch a chance to turn off.
     (run-hooks 'mouse-leave-buffer-hook)
+    (ignore-preserving-kill-region)
     (mouse-drag-track start-event)))
 
 ;; Inhibit the region-confinement when undoing mouse-drag-region
@@ -1708,7 +1710,8 @@ mouse-drag-track
                                             nil start-point))
                         ((>= mouse-row bottom)
                          (mouse-scroll-subr start-window (1+ (- mouse-row bottom))
-                                            nil start-point))))))))
+                                            nil start-point))))))
+                 (ignore-preserving-kill-region)))
              map)
            t (lambda ()
                (funcall cleanup)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32747: Be able to append mouse selections at the head of `kill-ring' (e.g, with C-M-w)

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So why is `C-w <drag-mouse-1>' different here?  The patch makes them
> behave the same way.
>
> If we don't want that, we have to come up with a whole nother way to
> implement `C-M-w', because it just sets last-command to `kill-region'.
>
> Opinions?

Nobody had an opinion, so I've now pushed this solution to Emacs 29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

> > > I don't understand why you address this to me although it's clear that
> > > I didn't retitle this bug.
> >
> > I replied to the last msg I got from this thread; sorry.
> 
> In which I said nothing about retitling.  So in what sense is this a
> "reply"?

Didn't know how to reply to the control action of retitling.
Again, sorry for bothering you.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Noam Postavsky]

retitle 32747 Be able to append mouse selections at the head of `kill-ring' (e.g, with C-M-w)
quit

>> > > I don't understand why you address this to me although it's clear that
>> > > I didn't retitle this bug.
>> >
>> > I replied to the last msg I got from this thread; sorry.
>> 
>> In which I said nothing about retitling.  So in what sense is this a
>> "reply"?
>
> Didn't know how to reply to the control action of retitling.
> Again, sorry for bothering you.

Welp, I guess the lesson here is to always send the retitling action to
the bug thread in addition to control.  I'll remember for next time.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

> Welp, I guess the lesson here is to always send the retitling action to
> the bug thread in addition to control.  I'll remember for next time.

I should have been more careful and figured it out. Sorry.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  32747@debbugs.gnu.org
> Date: Thu, 20 Sep 2018 18:16:22 -0400
> 
> I guess the lesson here is to always send the retitling action to
> the bug thread in addition to control.  I'll remember for next time.

Alternatively, there's nothing wrong with replying to the bug address
alone, when there's no clear-cut addressee.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

> > Didn't know how to reply to the control action of retitling.
> > Again, sorry for bothering you.
> 
> Welp, I guess the lesson here is to always send the retitling action to
> the bug thread in addition to control.  I'll remember for next time.

Hm.  Dunno - just a guess, but I wonder if this change in habit
might be responsible for a change I think I've been seeing over
the last few days.

Suddenly I'm getting zillions of messages from
control@debbugs.gnu.org.  I guess I'm getting all of them.
At first I thought maybe it was some kind of backlog, which
would clear itself up after a while.

I get hundreds of such control message per day now, which I
then have to delete.  In the past I think I only got such
messages for bugs I that submitted.

Or was there perhaps some other change that took effect
recently?  Is there some easy way for me to not receive
all of the control messages?

Sorry to bother you about this.  Thx.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Eli Zaretskii]

> Date: Mon, 29 Oct 2018 20:54:07 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 32747@debbugs.gnu.org
> 
> Suddenly I'm getting zillions of messages from
> control@debbugs.gnu.org.  I guess I'm getting all of them.
> At first I thought maybe it was some kind of backlog, which
> would clear itself up after a while.
> 
> I get hundreds of such control message per day now, which I
> then have to delete.  In the past I think I only got such
> messages for bugs I that submitted.
> 
> Or was there perhaps some other change that took effect
> recently?  Is there some easy way for me to not receive
> all of the control messages?

I have no idea what could cause that.  FWIW, I don't get anything from
control@debbugs.gnu.org except responses to my emails to that
address.  Could it be that you somehow subscribed to the
emacs-bug-tracker mailing list?

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

> I have no idea what could cause that.  FWIW, I don't get anything from
> control@debbugs.gnu.org except responses to my emails to that
> address.  Could it be that you somehow subscribed to the
> emacs-bug-tracker mailing list?

Could you tell/remind me how to check whether I'm subscribed
to that list and how to unsubscribe if I am?  Sorry for the
trouble.  I'm getting swamped by all of these control messages.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

> I don't understand why you address this to me although it's clear that
> I didn't retitle this bug.

I replied to the last msg I got from this thread; sorry.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Eli Zaretskii]

> Date: Thu, 20 Sep 2018 13:44:52 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 32747@debbugs.gnu.org
> 
> > I don't understand why you address this to me although it's clear that
> > I didn't retitle this bug.
> 
> I replied to the last msg I got from this thread; sorry.

In which I said nothing about retitling.  So in what sense is this a
"reply"?

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

> > Anyay, replaying the recipe now (again, from -Q), I see the bad
> > behavior in _all_ Emacs releases (including back to Emacs 20,
> > when there was no variable `mouse-drag-copy-region').
> 
> Makes sense, because those versions worked as if
> mouse-drag-copy-region was t.  Emacs 22.1 added that variable, and you
> should be able to see the problem go away starting from that version,
> when this variable is nil.

No. As I said, I checked Emacs 22.3.1 - to be exact:

GNU Emacs 22.3.1 (i386-mingw-nt6.2.9200) of 2008-09-06 on SOFT-MJASON

And the problem exists regardless of the value of `mouse-drag-copy-region'.
Setting the variable to nil has no effect in this regard - still the same problem.

> > In Emacs 23.4, changing `mouse-drag-copy-region' to nil does _not_
> > fix the behavior, for me. Are you sure that it does, for you?
> 
> Yes.  I just rechecked again, to be sure.  I don't understand why it
> doesn't work for you, maybe it's something specific to your system, or
> maybe that Emacs binary is somehow different from mine (unlikely).  Or
> maybe you made some mistake in reproducing the behavior in that
> version.

I've checked it multiple times now, each time from `emacs -Q'.
This is my Emacs 23.4 version:
GNU Emacs 23.4.1 (i386-mingw-nt6.2.9200) of 2012-02-04 on MARVIN

And I see the same thing in subsequent releases, as I said.
I'm on Windows 10. Nothing special about my Windows, AFAIK.

> > In Emacs 24.5 and later the bad behavior exists only when the
> > variable is non-nil.
> 
> When that variable is non-nil, what you see is expected behavior, see
> below.
> 
> > So the bug does not seem to be a regression, and it is longstanding.
> > Perhaps no one ever tried to use `C-M-w M-w' with a mouse
> > selection when testing?
> 
> Indeed, with that variable non-nil, users are not expected to copy and
> paste using the keyboard, they are expected to do that with the mouse.
> And they certainly aren't expected to mix both methods in the same
> sequence of actions on the same text.

I don't agree. Nothing in the description of `mouse-drag-copy-region'
suggests that with a non-nil value users are not expected to also
copy and paste using the keyboard. That would make no sense.

There is no reason that someone should not be able to use `C-M-w'
to affect copies/kills made with the mouse. And there is nothing in
the doc to suggest otherwise.

> > Do you agree that this is a bug?
> 
> No, I think it's expected.  When that variable is non-nil, making the
> second selection automatically copies the selected text into the
> kill-ring, so your C-M-w affects the next M-w, which copies the same
> text.  

I understand that that's what happens. But it's not what _should_
happen, IMO. `C-M-w' should make the following kill (or copy as
kill) append to the previous kill-ring entry, in general.

But in the case of the automatic copy  to the kill-ring just by
selecting with the mouse, that automatic copy should be replaced
by `C-M-w' when it is followed by another kill command.

I realize that that behavior was not implemented. But it's the
only behavior that makes sense, to allow `C-M-w' to work with
mouse selections.

So I stand by my report, but you can call it an enhancement
request if you prefer.

And until the requested enhancement is made there is a doc
problem for `C-M-w', as it does not call out the fact that it
doesn't append text selected with the mouse. AFAIK, there is no
way to use `C-M-w' to cause a mouse selection to be appended
to what was at the head of the kill-ring before that selection
was made.

> The text of the first selection should be available with M-y,
> as it is one slot down in the kill-ring (and should also be there
> twice, for the same reason).

There's no way, AFAIK, to get the mouse selection appended to
that first selection, as the top kill-ring entry. You cannot use
M-y anywhere in a sequence of actions with `C-M-w' to append
a mouse selection to that previous kill-ring entry.

> > To me, this is a bug. The behavior contradicts what the doc says for
> > `C-M-w', and the behavior is useless (why would anyone want
> > duplication of the mouse selection - appending it to itself instead
> > of the previous kill?)
> 
> You create the duplication by using M-w, because with that variable
> non-nil, there's no need for M-w, as selected text automatically gets
> placed in the kill-ring as soon as it is selected. 

Yes, I know.

I think you're not getting the point. There is no way to tell Emacs
to append the current mouse selection to the head of the kill-ring
as it was before the mouse selection, replacing that head with the
concatenation. Emacs provides `C-M-w' for that, but it cannot (so
far) be used to append a mouse selection.

The automatic copy-to-kill that happens with mouse selection is
a good thing. But it should not happen if the selection immediately
follows `C-M-w'. 

Not sure that's the fix, but it seems like it might be. The intended
effect is clear enough, as described above: `C-M-w' should be
able to have the effect that a subsequent mouse selection can be
appended to what was at the head of the ring before that mouse
selection.

Probably the fix needs to be made to `mouse-save-then-kill', not
to `append-next-kill': Don't copy selection as kill if previous
command is `append-next-kill'. But it's not enough to test
`last-command' for that, because `append-next-kill' sets
`this-command' to `kill-region'. Maybe checking whether
`real-last-command' is `append-last-kill' is sufficient.

> This mode is for people who select and copy/paste with the mouse,
> not with the keyboard.

I don't agree. And I don't agree that there are Emacs users who
select only with the mouse or only with the keyboard. Or even
if there are such people, I see no evidence that this variable (or
"mode") is only for such people.

But forget about this variable/mode.

The enhancement request is to be able to use `C-M-w' to have
Emacs append the mouse selection to the last kill (the one prior
to the implicit/automatic kill from making the mouse selection).

That's all.

> What documentation does this contradict? 

`C-M-w', but contradict is not the right word here.

Yes, technically it does do what it says. But it does not do what
one expects. It's not about whether it technically appends the
`M-w' copy (after `C-M-w') to the kill-ring head, which is the same
text. It's about there being no way to use `C-M-w' to let you 
append text selected with the mouse.

Please tell me how, using the mouse, you would select the first
word of this paragraph, and select the 5th word, and be able to
yank their concatenation. That's what `C-M-w' is for: letting you
copy/kill bits of text to the kill-ring, not as separate entries but
by concatenating them together as the head entry of the ring.

> Perhaps we should clarify
> that, but in general you are doing something unexpected: mixing the
> mouse-based selection and copy/paste paradigm with the keyboard-based
> one.  They are supposed to be separate, and the defaults since Emacs
> 24 make sure they are.

I don't think (1) mouse-based selection and copying to the kill-ring
and (2) keyboard-based selection and copying to the kill-ring are
unmixed. You can mix them freely, in any order, with no problem.

Emacs has no policy of limiting use of the mouse to people who
only use the mouse, and similarly for the keyboard.

The only thing that does not work, AFAIK, is what I've described
here.

And it's not even about mixing mouse and keyboard. Tell me how,
using _only_ the mouse, to select bits on noncontiguous text and
get their concatenation at the head of the kill-ring.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Eli Zaretskii]

> Date: Wed, 19 Sep 2018 11:24:50 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 32747@debbugs.gnu.org
> 
> > > Anyay, replaying the recipe now (again, from -Q), I see the bad
> > > behavior in _all_ Emacs releases (including back to Emacs 20,
> > > when there was no variable `mouse-drag-copy-region').
> > 
> > Makes sense, because those versions worked as if
> > mouse-drag-copy-region was t.  Emacs 22.1 added that variable, and you
> > should be able to see the problem go away starting from that version,
> > when this variable is nil.
> 
> No. As I said, I checked Emacs 22.3.1 - to be exact:
> 
> GNU Emacs 22.3.1 (i386-mingw-nt6.2.9200) of 2008-09-06 on SOFT-MJASON

I just tried that version, and I still see that mouse-drag-copy-region
changes the behavior.

> I've checked it multiple times now, each time from `emacs -Q'.
> This is my Emacs 23.4 version:
> GNU Emacs 23.4.1 (i386-mingw-nt6.2.9200) of 2012-02-04 on MARVIN
> 
> And I see the same thing in subsequent releases, as I said.
> I'm on Windows 10. Nothing special about my Windows, AFAIK.

I'm on XP, but that's where the difference ends.  I have no idea why
you see a different behavior, and I don't have Windows 10 nearby to
check what happens there.

> > Indeed, with that variable non-nil, users are not expected to copy and
> > paste using the keyboard, they are expected to do that with the mouse.
> > And they certainly aren't expected to mix both methods in the same
> > sequence of actions on the same text.
> 
> I don't agree. Nothing in the description of `mouse-drag-copy-region'
> suggests that with a non-nil value users are not expected to also
> copy and paste using the keyboard. That would make no sense.

You can do both, but when you mix them, you get 2 copies of each
kill/copy in the kill-ring.

> There is no reason that someone should not be able to use `C-M-w'
> to affect copies/kills made with the mouse. And there is nothing in
> the doc to suggest otherwise.

This behavior was never implemented.  If that is what you want, you
are asking for a new feature, not reporting a bug, let alone a
regression.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Drew Adams]

> > 1. emacs -Q
> > 2. (setq mouse-drag-copy-region t) ; Mouse selection copies to kill-ring.
> > 3. In *scratch*, select some text, e.g. "This buffer".
> > 4. Use `M-w' to copy the selected text to the kill ring.
> > 5. With the mouse, select some other text, e.g. "visit that file".
> > 6. Use `C-M-w M-w', to append the second selection to the first as the
> >    last kill.  The kill should thus be "This buffervisit that file".
> > 7. `C-y' to yank the last kill.
> >
> > The text yanked should be "This buffervisit that file".  Instead, it is
> > "visit that filevisit that file".  That is, the second selection is
> > added to the kill ring and appended to itself.
> 
> I see something almost opposite:
> 
>  . in Emacs 23.4, the above recipe produces the "wrong" behavior,
>    unless I set mouse-drag-copy-region to nil (it is t by default)
> 
>  . in Emacs 24 and later, mouse-drag-copy-region is nil by default, so
>    the recipe works in "emacs -Q" without any customizations, but if I
>    set mouse-drag-copy-region to t, I get the old "wrong" Emacs 23
>    behavior
> 
> So I wonder what is going on with your system that you seem to see
> such strikingly different results.

Thanks for checking this.

Apologies. Dunno what I was seeing, or thought I was seeing, for
Emacs 23.4. Perhaps I was mixed up by not realizing that the
default value for the variable was different, and perhaps not
testing both cases or something.

Anyay, replaying the recipe now (again, from -Q), I see the bad
behavior in _all_ Emacs releases (including back to Emacs 20,
when there was no variable `mouse-drag-copy-region').

In Emacs 23.4, changing `mouse-drag-copy-region' to nil does _not_
fix the behavior, for me. Are you sure that it does, for you? Both nil
and t values just duplicate the mouse selection - the first text selected
and copied to the kill-ring with `M-w' is not present in either case.

In Emacs 24.5 and later the bad behavior exists only when the
variable is non-nil.

So the bug does not seem to be a regression, and it is longstanding.
Perhaps no one ever tried to use `C-M-w M-w' with a mouse
selection when testing?

Do you agree that this is a bug? If not, do you agree that it is a
worthwhile enhancement request that `C-M-w' be able to affect
a mouse selection the same way it affects a selection made with
the keyboard?

To me, this is a bug. The behavior contradicts what the doc says for
`C-M-w', and the behavior is useless (why would anyone want
duplication of the mouse selection - appending it to itself instead
of the previous kill?)

(The same problem exists for an actual kill, BTW. E.g. following
`C-M-w' with `C-w' instead of `M-w'.)

That I see the problem in Emacs 23.4 with both values of the
variable, and I see it in older releases where the variable does
not exist yet, maybe provides a clue for fixing the bug; dunno.
Whatever is done now for the nil case works correctly.

bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region', if selected with mouse

[Eli Zaretskii]

> Date: Wed, 19 Sep 2018 06:51:40 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 32747@debbugs.gnu.org
> 
> Anyay, replaying the recipe now (again, from -Q), I see the bad
> behavior in _all_ Emacs releases (including back to Emacs 20,
> when there was no variable `mouse-drag-copy-region').

Makes sense, because those versions worked as if
mouse-drag-copy-region was t.  Emacs 22.1 added that variable, and you
should be able to see the problem go away starting from that version,
when this variable is nil.

> In Emacs 23.4, changing `mouse-drag-copy-region' to nil does _not_
> fix the behavior, for me. Are you sure that it does, for you?

Yes.  I just rechecked again, to be sure.  I don't understand why it
doesn't work for you, maybe it's something specific to your system, or
maybe that Emacs binary is somehow different from mine (unlikely).  Or
maybe you made some mistake in reproducing the behavior in that
version.

> In Emacs 24.5 and later the bad behavior exists only when the
> variable is non-nil.

When that variable is non-nil, what you see is expected behavior, see
below.

> So the bug does not seem to be a regression, and it is longstanding.
> Perhaps no one ever tried to use `C-M-w M-w' with a mouse
> selection when testing?

Indeed, with that variable non-nil, users are not expected to copy and
paste using the keyboard, they are expected to do that with the mouse.
And they certainly aren't expected to mix both methods in the same
sequence of actions on the same text.

> Do you agree that this is a bug?

No, I think it's expected.  When that variable is non-nil, making the
second selection automatically copies the selected text into the
kill-ring, so your C-M-w affects the next M-w, which copies the same
text.  The text of the first selection should be available with M-y,
as it is one slot down in the kill-ring (and should also be there
twice, for the same reason).

> To me, this is a bug. The behavior contradicts what the doc says for
> `C-M-w', and the behavior is useless (why would anyone want
> duplication of the mouse selection - appending it to itself instead
> of the previous kill?)

You create the duplication by using M-w, because with that variable
non-nil, there's no need for M-w, as selected text automatically gets
placed in the kill-ring as soon as it is selected.  This mode is for
people who select and copy/paste with the mouse, not with the
keyboard.

What documentation does this contradict?  Perhaps we should clarify
that, but in general you are doing something unexpected: mixing the
mouse-based selection and copy/paste paradigm with the keyboard-based
one.  They are supposed to be separate, and the defaults since Emacs
24 make sure they are.