GNU bug report logs - #60810
30.0.50; `while-no-input' in GUI(macOS) is much slower than emacs -nw

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: allenhw1996 <at> gmail.com, 60810 <at> debbugs.gnu.org
Subject: Re: bug#60810: 30.0.50;
 `while-no-input' in GUI(macOS) is much slower than emacs -nw
Date: Sun, 15 Jan 2023 09:08:17 +0200

> Cc: 60810 <at> debbugs.gnu.org
> Date: Sun, 15 Jan 2023 09:36:24 +0800
> From:  Po Lu via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Thanks.  This problem is because the NS port does not support
> interrupt-based input, because of limitations in Apple's toolkit.
> 
> This means Emacs is not notified immediately about new input while it is
> executing Lisp, and instead has to periodically check every 1 second.

Does NS use a separate thread to handle input events?  If so, could
that separate thread set quit-flag when we are under throw-on-input,
if it detects a suitable input event?  The w32 port does that, see
signal_user_input in w32fns.c.  This should allow the Lisp thread
detect that input is pending in a more timely fashion.

Previous Next

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