Simplification to mouse-avoidance-mode (patch) + redisplay bug?

Simplification to mouse-avoidance-mode (patch) + redisplay bug?

[Kim F. Storm]

Using posn-at-point seems to be much simpler than compute-motion:

Index: avoid.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/avoid.el,v
retrieving revision 1.40
diff -c -r1.40 avoid.el
*** avoid.el	6 Feb 2006 14:33:32 -0000	1.40
--- avoid.el	2 May 2006 12:19:57 -0000
***************
*** 139,161 ****
  (defun mouse-avoidance-point-position ()
    "Return the position of point as (FRAME X . Y).
  Analogous to `mouse-position'."
!   (let* ((w (selected-window))
! 	 (edges (window-inside-edges w))
! 	 (list
! 	  (compute-motion (max (window-start w) (point-min))   ; start pos
! 			  ;; window-start can be < point-min if the
! 			  ;; latter has changed since the last redisplay
! 			  '(0 . 0)	                       ; start XY
! 			  (point)	                       ; stop pos
! 			  nil				       ; stop XY: none
! 			  nil				       ; width
! 			  (cons (window-hscroll w) 0)          ; 0 may not be right?
! 			  (selected-window))))
!     ;; compute-motion returns (pos HPOS VPOS prevhpos contin)
!     ;; we want:               (frame hpos . vpos)
      (cons (selected-frame)
! 	  (cons (+ (car edges)       (car (cdr list)))
! 		(+ (car (cdr edges)) (car (cdr (cdr list))))))))
  
  ;(defun mouse-avoidance-point-position-test ()
  ;  (interactive)
--- 139,151 ----
  (defun mouse-avoidance-point-position ()
    "Return the position of point as (FRAME X . Y).
  Analogous to `mouse-position'."
!   (let ((edges (window-inside-edges))
! 	(x-y (posn-x-y (posn-at-point))))
      (cons (selected-frame)
! 	  (cons (+ (car edges)
! 		   (/ (car x-y) (frame-char-width)))
! 		(+ (car (cdr edges))
! 		   (/ (cdr x-y) (frame-char-height)))))))
  
  ;(defun mouse-avoidance-point-position-test ()
  ;  (interactive)



I notice that the final cursor shape often gets it wrong if I set the
style to "cat-and-mouse", it seems to happen if the cursor passes over
an area (eg. void or a mode line) along the chosen path.  That looks
like a redisplay bug.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Simplification to mouse-avoidance-mode (patch) + redisplay bug?

[Richard Stallman]

If you think your patch is correct, would you please install it?

    I notice that the final cursor shape often gets it wrong if I set the
    style to "cat-and-mouse", it seems to happen if the cursor passes over
    an area (eg. void or a mode line) along the chosen path.  That looks
    like a redisplay bug.

You're the expert on redisplay--could you debug it (and ack)?

Re: Simplification to mouse-avoidance-mode (patch) + redisplay bug?

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> If you think your patch is correct, would you please install it?
>
>     I notice that the final cursor shape often gets it wrong if I set the
>     style to "cat-and-mouse", it seems to happen if the cursor passes over
>     an area (eg. void or a mode line) along the chosen path.  That looks
>     like a redisplay bug.
>
> You're the expert on redisplay--could you debug it (and ack)?

I've debugged this far -- and need an X-pert (Jan?) to take over:


mouse-avoidance-mode 'animate uses set-mouse-position to move
the mouse cursor in ~10 steps to reach its end position.

If I type very slowly, approaching the window cursor to the mouse
cursor -- and don't type anything while the mouse cursor is moving,
everything works, i.e. the mouse cursor shape at the final destination
is ok.

If I type more quickly, the mouse cursor still moves in steps, but
it may end up with any of the cursor shapes it had along the path.

I put some trace output into xterm.c, and it seems that (in the first
case) for each call to x_set_mouse_position (which calls
XWarpPointer), the event loop receives a MotionNotify event
(event.type = 6) with the new mouse cursor position.

.. unless I hit a key while the mouse is moving (the second case).

As soon as emacs gets the key event (event.type = 2), no further
MotionNotify events are delivered for the remaining mouse positions
along the path.

This looks like an X bug.  This is the Xfree server from redhat 9.0.

A work-around could be to unconditionally call "note_mouse_movement"
in x_set_mouse_position ?



In GNU Emacs 22.0.50.8 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2006-05-09 on kfs-l.imdomain.dk
X server distributor `The XFree86 Project, Inc', version 11.0.40300000
configured using `configure  'CFLAGS=-O0 -g''

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Simplification to mouse-avoidance-mode (patch) + redisplay bug?

[Richard Stallman]

    As soon as emacs gets the key event (event.type = 2), no further
    MotionNotify events are delivered for the remaining mouse positions
    along the path.

    This looks like an X bug.  This is the Xfree server from redhat 9.0.

It could be an X bug.  If so, we should report it, but getting it
fixed in the users' machines will take time.  So we want to install
a work-around if that isn't too hard.

Re: Simplification to mouse-avoidance-mode (patch) + redisplay bug?

[Jan Djärv]

Kim F. Storm skrev:

> I've debugged this far -- and need an X-pert (Jan?) to take over:
> 
> 
> mouse-avoidance-mode 'animate uses set-mouse-position to move
> the mouse cursor in ~10 steps to reach its end position.
> 
> If I type very slowly, approaching the window cursor to the mouse
> cursor -- and don't type anything while the mouse cursor is moving,
> everything works, i.e. the mouse cursor shape at the final destination
> is ok.
> 
> If I type more quickly, the mouse cursor still moves in steps, but
> it may end up with any of the cursor shapes it had along the path.
> 
> I put some trace output into xterm.c, and it seems that (in the first
> case) for each call to x_set_mouse_position (which calls
> XWarpPointer), the event loop receives a MotionNotify event
> (event.type = 6) with the new mouse cursor position.
> 
> .. unless I hit a key while the mouse is moving (the second case).
> 
> As soon as emacs gets the key event (event.type = 2), no further
> MotionNotify events are delivered for the remaining mouse positions
> along the path.
> 
> This looks like an X bug.  This is the Xfree server from redhat 9.0.

Are you sure x_set_mouse_position is called?  When I hold down a key and let 
it repeat, mouse avoidance is not working at all (i.e. x_set_mouse_position is 
not called).  I suspect event processing takes all time so mouse avoidance 
does not get time to check where the cursor is.

Another thing is that X is not guaranteed to deliver MotionNotify for every 
pixel the mouse moves through.  It is actually undefined how many MotionNotify 
you will get when moiving the mouse, but you are guaranteed to get one 
MotionNotify when the mouse movement stops.

A third thing to check is if the XWarpPointer requests are queued or not.  You 
can add a call to XFlush after XWarpPointer and see if that improves the 
situation.

I tried, but could not reproduce the situation where the cursor shape is 
wrong.  I'm sure it is timing related, i.e. events not sent or received when 
expected to.

	Jan D.

Re: Simplification to mouse-avoidance-mode (patch) + redisplay bug?

[Kim F. Storm]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Kim F. Storm skrev:
>
>> I've debugged this far -- and need an X-pert (Jan?) to take over:
>>
>>
>> mouse-avoidance-mode 'animate uses set-mouse-position to move
>> the mouse cursor in ~10 steps to reach its end position.
>>
>> If I type very slowly, approaching the window cursor to the mouse
>> cursor -- and don't type anything while the mouse cursor is moving,
>> everything works, i.e. the mouse cursor shape at the final destination
>> is ok.
>>
>> If I type more quickly, the mouse cursor still moves in steps, but
>> it may end up with any of the cursor shapes it had along the path.
>>
>> I put some trace output into xterm.c, and it seems that (in the first
>> case) for each call to x_set_mouse_position (which calls
>> XWarpPointer), the event loop receives a MotionNotify event
>> (event.type = 6) with the new mouse cursor position.
>>
>> .. unless I hit a key while the mouse is moving (the second case).
>>
>> As soon as emacs gets the key event (event.type = 2), no further
>> MotionNotify events are delivered for the remaining mouse positions
>> along the path.
>>
>> This looks like an X bug.  This is the Xfree server from redhat 9.0.
>
> Are you sure x_set_mouse_position is called?

I put trace output int x_set_mouse_position, and it definitely gets
called (several times).

>                                               When I hold down a key
> and let it repeat, mouse avoidance is not working at all
> (i.e. x_set_mouse_position is not called).  I suspect event processing
> takes all time so mouse avoidance does not get time to check where the
> cursor is.

mouse-avoidance-mode runs via the idle timer, so if your keyboard
repeats too fast, emacs probably never runs the timer.

>
> Another thing is that X is not guaranteed to deliver MotionNotify for
> every pixel the mouse moves through.

Sure -- but it should deliver events for the (discrete) positions
set via XWarpPointer (according to the docs).

>                                       It is actually undefined how
> many MotionNotify you will get when moiving the mouse, but you are
> guaranteed to get one MotionNotify when the mouse movement stops.

The problem is that the MotionNotify event that you get is not the
final mouse position.

>
> A third thing to check is if the XWarpPointer requests are queued or
> not.  You can add a call to XFlush after XWarpPointer and see if that
> improves the situation.

It actually makes the situation worse -- now the final mouse shape
is wrong also when I type slowly, i.e. when I don't hit a key after
the mouse cursor starts moving.

>
> I tried, but could not reproduce the situation where the cursor shape
> is wrong.  I'm sure it is timing related, i.e. events not sent or
> received when expected to.

So, it is probably a bug in the (old) version of Xfree that I'm using,
and it looks like the bug is fixed in later versions.


I tried to add an explicit call to note_mouse_highlight after the
call to XWarpPointer, and it definitely has a positive effect,
but even with that change, the pointer shape ends up wrong in
some cases.

I'm not sure how important it is to fix this, but there is 
a patch which works for me -- of course a similar change
is probably needed in x_set_mouse_pixel_position.

*** xterm.c	10 May 2006 16:58:38 +0200	1.910
--- xterm.c	11 May 2006 11:52:27 +0200	
***************
*** 226,231 ****
--- 226,233 ----
  
  static unsigned long ignore_next_mouse_click_timeout;
  
+ static int ignore_next_motion_event;
+ 
  /* Mouse movement.
  
     Formerly, we used PointerMotionHintMask (in standard_event_mask)
***************
*** 6543,6548 ****
--- 6545,6556 ----
  
      case MotionNotify:
        {
+ 	if (ignore_next_motion_event)
+ 	  {
+ 	    ignore_next_motion_event = 0;
+ 	    goto OTHER;
+ 	  }
+ 
          previous_help_echo_string = help_echo_string;
          help_echo_string = Qnil;
  
***************
*** 8453,8458 ****
--- 8461,8471 ----
  
    XWarpPointer (FRAME_X_DISPLAY (f), None, FRAME_X_WINDOW (f),
  		0, 0, 0, 0, pix_x, pix_y);
+ 
+   last_mouse_motion_event.x = pix_x;
+   last_mouse_motion_event.y = pix_y;
+   note_mouse_movement (f, &last_mouse_motion_event);
+   ignore_next_motion_event = 1;
    UNBLOCK_INPUT;
  }
  
***************
*** 10795,10800 ****
--- 10808,10814 ----
    last_tool_bar_item = -1;
    any_help_event_p = 0;
    ignore_next_mouse_click_timeout = 0;
+   ignore_next_motion_event = 0;
  #ifdef HAVE_X_SM
    x_session_initialized = 0;
  #endif

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Simplification to mouse-avoidance-mode (patch) + redisplay bug?

[Jan Djärv]

>>                                       It is actually undefined how
>> many MotionNotify you will get when moiving the mouse, but you are
>> guaranteed to get one MotionNotify when the mouse movement stops.
> 
> The problem is that the MotionNotify event that you get is not the
> final mouse position.

Then there is abug somewhere.  It could be in X but it could also be in Emacs 
event handling, i.e. we are not reading events even if they are in the X input 
queue.

> 
>> A third thing to check is if the XWarpPointer requests are queued or
>> not.  You can add a call to XFlush after XWarpPointer and see if that
>> improves the situation.
> 
> It actually makes the situation worse -- now the final mouse shape
> is wrong also when I type slowly, i.e. when I don't hit a key after
> the mouse cursor starts moving.

I hope you added x_flush, not XFlush.  I see now that XFlush is defined to be 
empty in xterm.c.  If an XSync after WarpPointer doesn't get you all events 
then there is a bug in X.

> 
>> I tried, but could not reproduce the situation where the cursor shape
>> is wrong.  I'm sure it is timing related, i.e. events not sent or
>> received when expected to.
> 
> So, it is probably a bug in the (old) version of Xfree that I'm using,
> and it looks like the bug is fixed in later versions.

Are you running with SYNC_INPUT or not?

> 
> 
> I tried to add an explicit call to note_mouse_highlight after the
> call to XWarpPointer, and it definitely has a positive effect,
> but even with that change, the pointer shape ends up wrong in
> some cases.
> 
> I'm not sure how important it is to fix this, but there is 
> a patch which works for me -- of course a similar change
> is probably needed in x_set_mouse_pixel_position.
> 

This patch has flaws, there may be several calls to XWarpPointer before we see 
any MotionNotify events.

	Jan D.

> *** xterm.c	10 May 2006 16:58:38 +0200	1.910
> --- xterm.c	11 May 2006 11:52:27 +0200	
> ***************
> *** 226,231 ****
> --- 226,233 ----
>   
>   static unsigned long ignore_next_mouse_click_timeout;
>   
> + static int ignore_next_motion_event;
> + 
>   /* Mouse movement.
>   
>      Formerly, we used PointerMotionHintMask (in standard_event_mask)
> ***************
> *** 6543,6548 ****
> --- 6545,6556 ----
>   
>       case MotionNotify:
>         {
> + 	if (ignore_next_motion_event)
> + 	  {
> + 	    ignore_next_motion_event = 0;
> + 	    goto OTHER;
> + 	  }
> + 
>           previous_help_echo_string = help_echo_string;
>           help_echo_string = Qnil;
>   
> ***************
> *** 8453,8458 ****
> --- 8461,8471 ----
>   
>     XWarpPointer (FRAME_X_DISPLAY (f), None, FRAME_X_WINDOW (f),
>   		0, 0, 0, 0, pix_x, pix_y);
> + 
> +   last_mouse_motion_event.x = pix_x;
> +   last_mouse_motion_event.y = pix_y;
> +   note_mouse_movement (f, &last_mouse_motion_event);
> +   ignore_next_motion_event = 1;
>     UNBLOCK_INPUT;
>   }
>   
> ***************
> *** 10795,10800 ****
> --- 10808,10814 ----
>     last_tool_bar_item = -1;
>     any_help_event_p = 0;
>     ignore_next_mouse_click_timeout = 0;
> +   ignore_next_motion_event = 0;
>   #ifdef HAVE_X_SM
>     x_session_initialized = 0;
>   #endif
> 
> --
> Kim F. Storm <storm@cua.dk> http://www.cua.dk
> 
> 
> 
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Simplification to mouse-avoidance-mode (patch) + redisplay bug?

[Kim F. Storm]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Then there is abug somewhere.  It could be in X but it could also be
> in Emacs event handling, i.e. we are not reading events even if they
> are in the X input queue.

It is very consistent -- as soon as a key is hit, any "left over"
mouse positions set via XWarpPointer are not reported (as MotionNotify
events).

> I hope you added x_flush,

I did.

> Are you running with SYNC_INPUT or not?

not.

>> I'm not sure how important it is to fix this, but there is a patch
>> which works for me -- of course a similar change
>> is probably needed in x_set_mouse_pixel_position.
>>
>
> This patch has flaws, there may be several calls to XWarpPointer
> before we see any MotionNotify events.

Sure.  I don't think the patch should be installed.

I would better leave this as is -- as it seems to be fixed
in more recent X implementations.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk