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

[Andrew Schein <andrew@andrewschein.com>]

[-- 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
  		  {