[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#60810: 30.0.50; `while-no-input' in GUI(macOS) is much slower than e
From: |
Eli Zaretskii |
Subject: |
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@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@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.