bug#9186: drag copy buffer blown away by slight mouse movements on emacs 23.3.1 with GTK

bug#9186: drag copy buffer blown away by slight mouse movements on emacs 23.3.1 with GTK

[Andrew Schein]

[-- Attachment #1.1: Type: text/plain, Size: 1583 bytes --]

This bug concerns the X11 style drag copy (and middle mouse button paste) on
GNU emacs 23.  I noticed this problem on systems employing GTK, and haven't
had the opportunity to try other systems.

I have attached a ogv formatted video showing the problem.

Since I didn't have a working mic, here is a narration.

I open emacs using -q.  You can see the message:
This is GNU Emacs 23.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.20.1).
The system is Ubuntu 10.04.

I then proceed to drag over some text in the buffer.

I then left click a character moving the mouse _slightly_ downward.  The
message "Mark set" appears at the bottom of the buffer.

The last action is to move the mouse pointer elsewhere in the buffer and
middle click.  To my surprise the text is no-longer available.

Discussion:  some sequence of calls either leading to or because of the
mark-setting is blowing away the drag copy buffer.  The "mark set" message
does not seem like adequate warning or explanation for this.  Note that the
mouse movement was not sufficient to replace the drag-copy buffer with any
new text. Instead what was there is forgotten.  When I try to reproduce
emacs-like sensitivity in firefox (used as a gmail client) the text only
seems to be blown away when I moved the mouse enough to place some new text
there.  Furthermore, in firefox, if I accidently slip and move the mouse
while clicking the left button my drag copy buffer is not blown away as long
as I move the pointer back to its original position before releasing.

Cheers,

Andy

-- 
Andrew I. Schein
www.andrewschein.com

[-- Attachment #1.2: Type: text/html, Size: 1744 bytes --]

[-- Attachment #2: emacs_bug.ogv --]
[-- Type: video/ogg, Size: 1572579 bytes --]

bug#9186: patch for buggy drag behavior affecting emacs >=23

[Andrew Schein]

Below is my fix to bug#9186.  I located the area of the C code that
deals with recording click events and noticed that there is logic that
looks for extremely precise pixel placement rather than buffer
position.  In my opinion this leads to unexpected behavior; humans can not
move their hands so precisely as they can reliably move their mouse to
the area defined by fuzz.  On the other hand, there are plenty of cues
to indicate when the mouse is placed back into the original position.

In proposing this fix I am a a little concerned about how the overall
system will be effected.  Why was this click_fuzz logic introduced to
begin with?


*** ./src/keyboard.c    2011-08-15 16:25:02.516887000 -0700
--- ../copy2/trunk/src/keyboard.c    2011-08-17 08:58:01.792927000 -0700
***************
*** 5630,5637 ****
              event->modifiers |= click_modifier;
              ignore_mouse_drag_p = 0;
            }
!         else if (EQ (Fcar (Fcdr (start_pos)), Fcar (Fcdr (position))))
!           /* Mouse has returned to its original position.  */
            event->modifiers |= click_modifier;
          else
            {
--- 5630,5649 ----
              event->modifiers |= click_modifier;
              ignore_mouse_drag_p = 0;
            }
!         else if (xdiff < double_click_fuzz && xdiff > - double_click_fuzz
!              && ydiff < double_click_fuzz && ydiff > - double_click_fuzz
!           /* Maybe the mouse has moved a lot, caused scrolling, and
!              eventually ended up at the same screen position (but
!              not buffer position) in which case it is a drag, not
!              a click.  */
!             /* FIXME: OTOH if the buffer position has changed
!                because of a timer or process filter rather than
!                because of mouse movement, it should be considered as
!                a click.  But mouse-drag-region completely ignores
!                this case and it hasn't caused any real problem, so
!                it's probably OK to ignore it as well.  */
!             && EQ (Fcar (Fcdr (start_pos)), Fcar (Fcdr (position))))
!           /* Mouse hasn't moved (much).  */
            event->modifiers |= click_modifier;
          else
            {

--
Andrew I. Schein
www.andrewschein.com

bug#9186: patch for buggy drag behavior affecting emacs >=23

[Andrew Schein]

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

This is a resend, since my patch appears mangled in the archives.  I
am attaching the patch this time.

On Wed, Aug 17, 2011 at 9:13 AM, Andrew Schein <andrew@andrewschein.com> wrote:
> Below is my fix to bug#9186.  I located the area of the C code that
> deals with recording click events and noticed that there is logic that
> looks for extremely precise pixel placement rather than buffer
> position.  In my opinion this leads to unexpected behavior; humans can not
> move their hands so precisely as they can reliably move their mouse to
> the area defined by fuzz.  On the other hand, there are plenty of cues
> to indicate when the mouse is placed back into the original position.
>
> In proposing this fix I am a a little concerned about how the overall
> system will be effected.  Why was this click_fuzz logic introduced to
> begin with?
>



-- 
Andrew I. Schein
www.andrewschein.com

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1407 bytes --]

*** ./src/keyboard.c	2011-08-15 16:25:02.516887000 -0700
--- ../copy2/trunk/src/keyboard.c	2011-08-17 08:58:01.792927000 -0700
***************
*** 5630,5637 ****
  		    event->modifiers |= click_modifier;
  		    ignore_mouse_drag_p = 0;
  		  }
! 		else if (EQ (Fcar (Fcdr (start_pos)), Fcar (Fcdr (position))))
! 		  /* Mouse has returned to its original position.  */
  		  event->modifiers |= click_modifier;
  		else
  		  {
--- 5630,5649 ----
  		    event->modifiers |= click_modifier;
  		    ignore_mouse_drag_p = 0;
  		  }
! 		else if (xdiff < double_click_fuzz && xdiff > - double_click_fuzz
! 			 && ydiff < double_click_fuzz && ydiff > - double_click_fuzz
! 		  /* Maybe the mouse has moved a lot, caused scrolling, and
! 		     eventually ended up at the same screen position (but
! 		     not buffer position) in which case it is a drag, not
! 		     a click.  */
! 		    /* FIXME: OTOH if the buffer position has changed
! 		       because of a timer or process filter rather than
! 		       because of mouse movement, it should be considered as
! 		       a click.  But mouse-drag-region completely ignores
! 		       this case and it hasn't caused any real problem, so
! 		       it's probably OK to ignore it as well.  */
! 		    && EQ (Fcar (Fcdr (start_pos)), Fcar (Fcdr (position))))
! 		  /* Mouse hasn't moved (much).  */
  		  event->modifiers |= click_modifier;
  		else
  		  {

bug#9186: drag copy buffer blown away by slight mouse movements on emacs 23.3.1 with GTK

[Chong Yidong]

Andrew Schein <andrew@andrewschein.com> writes:

> Discussion: some sequence of calls either leading to or because of the
> mark-setting is blowing away the drag copy buffer. The "mark set"
> message does not seem like adequate warning or explanation for this.
> Note that the mouse movement was not sufficient to replace the
> drag-copy buffer with any new text. Instead what was there is
> forgotten.

This bug is fixed with the mouse-selection code in Emacs 24 (the primary
selection is no longer emptied out unless overwritten by a mouse
selection).  The patch you supplied does not seem to be necessary, in
this light; anyway it is not right since it makes it hard to use the
mouse to select a single character.  Closing the bug; thanks for the
report.