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

[Eli Zaretskii <eliz@gnu.org>]

> 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.