bug#675: 23.0.60; Edebugging track-mouse

bug#675: 23.0.60; Edebugging track-mouse

[Lars Magne Ingebrigtsen]

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

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

I can confirm that this issue still exists in Emacs 24.

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

bug#675: 23.0.60; Edebugging track-mouse

[Xue Fuqiao]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> (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).
>
> I can confirm that this issue still exists in Emacs 24.

I can't reproduce it with Emacs 24.3.50.  `g' continues without stopping.

-- 
http://www.gnu.org/software/emacs/

bug#675: 23.0.60; Edebugging track-mouse

[npostavs]

found 675 24.3
found 675 24.5
found 675 25.0.95
quit

Xue Fuqiao <xfq@gnu.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>>> (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).
>>
>> I can confirm that this issue still exists in Emacs 24.
>
> I can't reproduce it with Emacs 24.3.50.  `g' continues without stopping.

I managed to reproduce with 24.3, 24.4, 24.5, and 25.0.95; though not
with 23.4, 24.1, or 24.2.  What's a bit unclear in the OP, is that I had
to move the mouse while (foo) is being called, i.e., M-: (foo) {while
moving mouse hit RET}.

bug#675: 23.0.60; Edebugging track-mouse

[Lars Ingebrigtsen]

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

bug#675: 23.0.60; Edebugging track-mouse

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Sun, 20 Oct 2019 09:36:56 +0200
> 
> 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?

Can Edebug bind while-no-input-ignore-events to something appropriate
to rectify this?

bug#675: 23.0.60; Edebugging track-mouse

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?
>
> Can Edebug bind while-no-input-ignore-events to something appropriate
> to rectify this?

Hm...  I'm completely unfamiliar with that variable.

@defvar while-no-input-ignore-events
This variable allow setting which special events @code{while-no-input}
should ignore.  It is a list of symbols.

Perhaps the manual should mention what kind of symbols?

Anyway, I can't see that edebug calls while-no-input?

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

bug#675: 23.0.60; Edebugging track-mouse

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: bojohan+mail@dd.chalmers.xn--se,  675@debbugs.gnu.org
> Date: Sun, 20 Oct 2019 13:21:08 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> @defvar while-no-input-ignore-events
> This variable allow setting which special events @code{while-no-input}
> should ignore.  It is a list of symbols.
> 
> Perhaps the manual should mention what kind of symbols?

See subr.el.

> Anyway, I can't see that edebug calls while-no-input?

I don't remember the details of the implementation, but if you already
tried that and it didn't help in this case, I guess that cannot solve
the issue.

bug#675: 23.0.60; Edebugging track-mouse

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Perhaps the manual should mention what kind of symbols?
>
> See subr.el.

;; Don't throw `throw-on-input' on those events by default.
(setq while-no-input-ignore-events
      '(focus-in focus-out help-echo iconify-frame
        make-frame-visible selection-request buffer-switch))

>> Anyway, I can't see that edebug calls while-no-input?
>
> I don't remember the details of the implementation, but if you already
> tried that and it didn't help in this case, I guess that cannot solve
> the issue.

I didn't know what kind of events to bind the variable to to make it
ignore the mouse movements.

I've now tried (in edebug--recursive-edit) to bind it to

              (while-no-input-ignore-events '(mouse-movement))

but it seems to make no difference.

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

bug#675: 23.0.60; Edebugging track-mouse

[Lars Ingebrigtsen]

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

> (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").

I've now fixed this with a gross hack in Emacs 29.

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