GNU bug report logs - #17211
Empty items show up in kill-ring if mouse-drag-copy-region is used

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17211 in the body.
You can then email your comments to 17211 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Richard Smith <rsmithnews <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Empty items show up in kill-ring if mouse-drag-copy-region is used
Date: Sun, 6 Apr 2014 14:53:21 -0700

[Message part 1 (text/plain, inline)]

Emacs version: 24.3.1
Platform: Windows 7, confirmed in Linux

Problem:

Windows users who set up Emacs to cut/paste from the kill-ring get empty
paste results.

Details:

Windows users who are having difficulty with cut/paste behavior are often
advised to do the following:

(setq select-active-regions nil)
(setq mouse-drag-copy-region t)
(global-set-key [mouse-2] 'mouse-yank-at-click)

But if, in the process of pasting text, you click, then drag the mouse even
a few pixels, this causes an empty string to go into the kill-ring, so a
subsequent paste inserts nothing, but an examination of the kill-ring
indicates the desired paste value has been pushed down by the empty string.

Steps to reproduce:

1. Enter lisp-interaction mode.

2. Set up the "normal behavior" by executing this form:

(progn
  (setq select-active-regions t)
  (setq mouse-drag-copy-region nil)
  (global-set-key [mouse-2] 'mouse-yank-primary))

3. Select some text buy dragging mouse-1 over it.

4. Move to a different area in the buffer and set point with down-mouse-1,
but move the mouse a few pixels so you see the "Mark Set" message.

5. Paste the text with down-mouse-2.

6. Observe the correct behavior (text gets pasted).

7. Now, set up the "modified behavior" by executing this form:

(progn
  (setq select-active-regions nil)
  (setq mouse-drag-copy-region t)
  (global-set-key [mouse-2] 'mouse-yank-at-click))

8. Repeat steps 3 thru 5.

9. Observe that nothing is pasted.

10. Execute the following form to "fix" the problem:

(progn
  (setq kill-ring (remove "" kill-ring))
  (setq kill-ring-yank-pointer kill-ring))

11. Do the mouse-2 paste again, observe that it worked this time.

[Message part 2 (text/html, inline)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Richard Smith <rsmithnews <at> gmail.com>
Cc: 17211 <at> debbugs.gnu.org
Subject: Re: bug#17211: Empty items show up in kill-ring if
 mouse-drag-copy-region is used
Date: Wed, 11 May 2022 15:31:29 +0200

Richard Smith <rsmithnews <at> gmail.com> writes:

> 7. Now, set up the "modified behavior" by executing this form: 
>
> (progn 
>   (setq select-active-regions nil) 
>   (setq mouse-drag-copy-region t) 
>   (global-set-key [mouse-2] 'mouse-yank-at-click)) 
>
> 8. Repeat steps 3 thru 5. 
>
> 9. Observe that nothing is pasted. 

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I can reproduce the behaviour you're seeing in Emacs 29, but I'm not
sure what else Emacs could do here.  With `mouse-drag-copy-region' set,
and in 4) you drag the mouse, so it copies that new region (even if that
region is so short that you end up with "").

Hm...  well, I guess we could change mouse-drag-copy-region so that if
the region is very short (i.e., less than a character), then we don't
put that onto the kill ring?

Does anybody here object to making such a change?  I guess it's possible
that somebody is using a sub-character drag to set the mark, but it does
seem unlikely.

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

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Richard Smith <rsmithnews <at> gmail.com>
Cc: "17211 <at> debbugs.gnu.org" <17211 <at> debbugs.gnu.org>
Subject: RE: [External] : bug#17211: Empty items show up in kill-ring if
 mouse-drag-copy-region is used
Date: Wed, 11 May 2022 14:35:00 +0000

> I can reproduce the behaviour you're seeing in Emacs 29, but I'm not
> sure what else Emacs could do here.  With `mouse-drag-copy-region' set,
> and in 4) you drag the mouse, so it copies that new region (even if
> that
> region is so short that you end up with "").
> 
> Hm...  well, I guess we could change mouse-drag-copy-region so that if
> the region is very short (i.e., less than a character), then we don't
> put that onto the kill ring?
> 
> Does anybody here object to making such a change?  I guess it's
> possible
> that somebody is using a sub-character drag to set the mark, but it
> does
> seem unlikely.

Please don't "fix" this.  This is pilot error.
Users can usually configure their mouse to
compensate for any unsteady hand etc.  Or if
necessary and this is considered an Emacs-only
problem, then Emacs could add a user option to
adjust the behavior.

But there should be no one-size-fits-all change.
It's perfectly fine to _be able_ to drag to
select whitespace, and it's perfectly fine to
have whitespace on the kill-ring and to yank it.

If the problem is (1) some users not wanting a
tiny movement to select whitespace, or (2) users
not wanting whitespace on the kill-ring, then
find another solution for such users, by way of
one or more user options.

Note that the way this bug report and its title
are worded suggest #2 - the reporting user seems
to think that whitespace is inappropriate for
the kill-ring.  A user option could easily take
care of that preference.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Richard Smith <rsmithnews <at> gmail.com>
Cc: 17211 <at> debbugs.gnu.org
Subject: Re: bug#17211: Empty items show up in kill-ring if
 mouse-drag-copy-region is used
Date: Thu, 09 Jun 2022 15:58:11 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Hm...  well, I guess we could change mouse-drag-copy-region so that if
> the region is very short (i.e., less than a character), then we don't
> put that onto the kill ring?
>
> Does anybody here object to making such a change?  I guess it's possible
> that somebody is using a sub-character drag to set the mark, but it does
> seem unlikely.

Out of an overabundance of caution, I've now added a new value to
mouse-drag-copy-region to do this, even if I don't think anybody would
want those ""s to land in the kill ring.  (Emacs 29.)

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

Previous Next

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