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

[Daniel Colascione <dancol@dancol.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.



>
>I know nothing about the "NS event loop", so I'm probably missing
>something.
>



>Thanks.