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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Daniel Colascione <dancol <at> dancol.org>
Subject: bug#73559: closed (Re: bug#73559: [PATCH] fix NS build focus-in
 event processing)
Date: Sat, 05 Oct 2024 10:38:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

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

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 73559 <at> debbugs.gnu.org.

-- 
73559: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73559
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: luangruo <at> yahoo.com, 73559-done <at> debbugs.gnu.org
Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing
Date: Sat, 05 Oct 2024 13:37:14 +0300

> Date: Mon, 30 Sep 2024 10:50:31 -0700
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: luangruo <at> yahoo.com, 73559 <at> debbugs.gnu.org
> 
> 
> 
> On September 30, 2024 10:40:57 AM PDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> Date: Mon, 30 Sep 2024 10:05:09 -0700
> >> From: Daniel Colascione <dancol <at> dancol.org>
> >> CC: luangruo <at> yahoo.com, 73559 <at> debbugs.gnu.org
> >> 
> >> It's not that the NS pselect waits too long. It's that it doesn't know to wake up. The focus event is delivered to Emacs by NS as a callback. Unless that callback, one way or another, takes some action to wake up the event loop, nothing gets processed. On Windows, we drain the event queue as a side effect of the message pump, whereas on NS there doesn't seem to be a separate pump that works this way -- just a callback.
> >
> >What about making pselect wait on one more descriptor, to which the
> >callback could then write?
> 
> That's the moral equivalent of what my patch does. My patch just uses the existing machinery for waking the main thread instead of adding a new FD.

The patch was installed on the master branch, so I'm closing this bug.

Thanks.

[Message part 3 (message/rfc822, inline)]

From: Daniel Colascione <dancol <at> dancol.org>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] fix NS build focus-in event processing
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.

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.

commit c6d98bfc2a098b57fa9631978224ead2668d3a88
Author: Daniel Colascione <dancol <at> dancol.org>
Date:   Wed Aug 21 19:48:05 2024 -0700

    process events on focus in

diff --git a/src/nsterm.m b/src/nsterm.m
index 8c405738467..f68a22d9fbc 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -7973,6 +7973,7 @@ - (void)windowDidBecomeKey      /* for direct calls */
   event.kind = FOCUS_IN_EVENT;
   XSETFRAME (event.frame_or_window, emacsframe);
   kbd_buffer_store_event (&event);
+  ns_send_appdefined (-1);  // Kick main loop
 }
 
 

Previous Next

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