|
From: | Farblos |
Subject: | 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 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0 |
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.
[Prev in Thread] | Current Thread | [Next in Thread] |