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

Previous Next

Full log

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

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

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.



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



>Thanks.

Previous Next

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