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

Previous Next

Full log

Message #17 received at 73559 <at> debbugs.gnu.org (full text, mbox):

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

On September 30, 2024 8:38:18 AM PDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 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.

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?

Previous Next

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