GNU bug report logs - #60817
28.2; `x-focus-frame' causes spurious input events causes edebug not showing intermediate results

Previous Next

Full log

Message #11 received at 60817 <at> debbugs.gnu.org (full text, mbox):

From: Farblos <akfkqu.9df7rp <at> vodafonemail.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60817 <at> debbugs.gnu.org
Subject: Re: bug#60817: 28.2; `x-focus-frame' causes spurious input events
 causes edebug not showing intermediate results
Date: Sat, 21 Jan 2023 21:03:41 +0100

On 2023-01-15  07:23, Eli Zaretskii wrote:

> AFAIU, input-pending-p should filter out focus events, so I don't
> think I understand why you see this.  Can you try this in Emacs 29 or
> the master branch of the Emacs Git repository, so we make sure this
> problem was not fixed already?  If it still happens in those newer
> versions, maybe you can step with GDB through get_input_pending, when
> it's called from input-pending-p, and through readable_events called
> by get_input_pending, and see why focus events aren't filtered out?

I used printf debugging and, admittedly, even back in Emacs 27 for now, 
since I have the Debian toolchain ready for that.  I reduced the test 
case to this:

(defun testcase ()
  (interactive)
  (message "pre: %S" (input-pending-p))
  (x-focus-frame (selected-frame))
  (sleep-for 0.5)
  (message "pst: %S" (input-pending-p)))

The error ("pst: t") reproduces only after touching some part of the 
modeline that provides a tooltip.

And the offending event that causes `input-pending-p' to become t is 
*not* a focus event (I can see indeed these getting filtered in 
readable_events) but rather a HELP_EVENT.  So as soon as one has touched 
the modeline, the call to `x-focus-frame' produces these HELP_EVENTS.

Does that ring a bell?  Any new directions where I should look at?

I'll try setting up a build environment for a newer Emacs when I find 
the time to do so.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.