GNU bug report logs - #73559
[PATCH] fix NS build focus-in event processing

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: luangruo <at> yahoo.com, 73559 <at> debbugs.gnu.org
Subject: bug#73559: [PATCH] fix NS build focus-in event processing
Date: Mon, 30 Sep 2024 19:29:09 +0300

> Date: Mon, 30 Sep 2024 08:51:27 -0700
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: luangruo <at> yahoo.com, 73559 <at> debbugs.gnu.org
> 
> >That's not what I meant.  kbd_buffer_store_event doesn't trigger
> >reading from the queue, AFAIU.  Emacs does that itself, when it
> >becomes idle: it calls read_char as part of its main loop, and that
> >reads from the input queue.
> 
> Yes. So now imagine that Emacs is idle and not the focused window. I command-tab to it. Now Emacs is the focused window. I would expect Emacs to have run the functions in focus-in-hook by now, but it didn't, because when we got focus, we queued the focus event but didn't wake up the main thread to process it. Now I hit a key. Emacs wakes up, drains its event loop (firing off focus-in-hook functions), and processes my keystroke. Isn't it correct for Emacs to run that hook immediately when it gets focus, not some time after?

Yes, of course it is.

What happens on MS-Windows in this case is that when the Emacs frame
gets focus, we are sent the WM_SETFOCUS message.  That causes us to
add to the input queue (by using kbd_buffer_store_event) an input
event whose event->kind is FOCUS_IN_EVENT.  Immediately after that, I
see read_char call kbd_buffer_get_event (via several intermediate
calls), and the FOCUS_IN_EVENT is read and processed

I wonder why this doesn't happen for NS.  (But I know that the NS port
uses some tricky code to process events, so I'm hardly surprised.)

> In general, I don't see why we'd wire it up such that the event queue can be non-empty and the main thread asleep indefinitely. If we have an event to process, then in all circumstances, we should process it, yes?

Yes, definitely.  And AFAIU that should happen because we call
read_char whenever we are idle.  Maybe the NS version of pselect
sleeps indefinitely or for too long if no keyboard keys are pressed?
On other systems, any message from the window-system exits pselect,
but maybe that doesn't happen on NS?

Does having a frequently-expiring timer cause the focus-in events to
be processed more timely, without your patch?

Previous Next

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