bug#675: 23.0.60; Edebugging track-mouse

[Lars Ingebrigtsen <larsi@gnus.org>]

bojohan+mail@dd.chalmers.se (Johan "Bockgård)" writes:

> emacs -Q
>
> (defun foo ()
>   (track-mouse (ignore) (ignore)))
>
> Instrument the function with C-u C-M-x.
>
> Move the mouse. (Don't click.)
>
> Call (foo)
>
> Press "g". Edebug stops at each expresson inside track-mouse (repeat
> "g").
>
> Expected results: "g" should continue without stopping (only at
> breakpoints).
>
> If the last mouse action was a click the problem doesn't happen.

The code that's causing this is

            (when (input-pending-p)
	      (setq edebug-stop t)
	      (setq edebug-execution-mode 'step) ; for `edebug-overlay-arrow'
	      (edebug-stop))

because when you're tracking the mouse (and you move it), you'll have
input pending, I think?  Hm...  No, it's not that simple -- just moving
the mouse before calling (foo) also triggers this.

Hm!

This gets stranger and stranger.  Here's a simple test case:  Move the
mouse (don't click it), and then eval this:

(track-mouse (input-pending-p))

I get t.  If the last mouse action is a click, then it evaluates to nil.

Right.  Move the mouse (don't click) and then evaluate:

(track-mouse (when (input-pending-p) (read-event "foo: ")))
=> (mouse-movement (#<window 4824 on *unsent wide reply to Johan "Bockgård*> 892 (863 . 529) 1948101423 nil 892 (57 . 17) nil (398 . 19) (15 . 30)))

So `track-mouse' will give you the previous mouse movement?  OK, that's
fine I guess.

But back to the original problem:  (input-pending-p) is non-nil here,
but it's because of a mouse movement, which edebug doesn't care about.

I guess edebug really cares about unread-command-events here?  So
changing the call to just examine that instead might be the fix?

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