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

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

[Richard Smith]

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

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.

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

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

[Lars Ingebrigtsen]

Richard Smith <rsmithnews@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

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

[Drew Adams]

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@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