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

Previous Next

Full log

Message #17 received at 32747 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>
Cc: 32747 <at> debbugs.gnu.org
Subject: RE: bug#32747: 26; `C-M-w M-w' with non-nil `mouse-drag-copy-region',
 if selected with	mouse
Date: Wed, 19 Sep 2018 11:24:50 -0700 (PDT)

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

Previous Next

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