bug#73559: [PATCH] fix NS build focus-in event processing

[Daniel Colascione <dancol@dancol.org>]

On September 30, 2024 8:38:18 AM PDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Mon, 30 Sep 2024 07:20:26 -0700
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: 73559@debbugs.gnu.org
>> 
>> 
>> 
>> On September 30, 2024 4:41:49 AM PDT, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> From: Daniel Colascione <dancol@dancol.org>
>> >> Date: Sun, 29 Sep 2024 22:47:46 -0400
>> >> 
>> >> 
>> >> In Emacs NS build, frames don't respond to focus-in events right away.
>> >> Instead, they store the focus-in event and process it (and other queued
>> >> events) whenever some other event happens to occur on that frame.
>> >
>> >Hmm... isn't this the same on all other GUI systems?
>> >kbd_buffer_store_event adds the event to the Emacs input queue, and
>> >AFAIU it will be processed as soon as Emacs gets back to its main loop
>> >and calls read_char.  No other event should be needed, AFAIK.  Po Lu,
>> >am I missing something here?
>> >
>> >> This patch kicks the NS event loop immediately when a focus-in event
>> >> happens, allowing Emacs to respond to focus-in events without some other
>> >> event triggering the processing.
>> 
>> I don't recall what we do for other systems, but for NS, we don't wake up the event loop as a side effect of kbd_buffer_store_event by itself. We rely on something else waking up the loop draining events from the queue. Changing the kbd_buffer_store_to_event to wake the main thread unconditionally would be another option, but seemed like a bigger change.
>
>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?

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?