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

[Eli Zaretskii <eliz@gnu.org>]

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