GNU bug report logs -
#73559
[PATCH] fix NS build focus-in event processing
Previous Next
Full log
View this message in rfc822 format
> Date: Mon, 30 Sep 2024 07:20:26 -0700
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: 73559 <at> debbugs.gnu.org
>
>
>
> On September 30, 2024 4:41:49 AM PDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> From: Daniel Colascione <dancol <at> 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.
This bug report was last modified 230 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.