From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#73559: [PATCH] fix NS build focus-in event processing Date: Mon, 30 Sep 2024 19:29:09 +0300 Message-ID: <86ed512jhm.fsf@gnu.org> References: <871q113lil.fsf@dancol.org> <86v7yd2wsi.fsf@gnu.org> <86h69x2lud.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15031"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 73559@debbugs.gnu.org To: Daniel Colascione Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 30 18:29:48 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1svJHQ-0003nG-Mo for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Sep 2024 18:29:48 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1svJHC-00036M-A0; Mon, 30 Sep 2024 12:29:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1svJHA-00034s-6k for bug-gnu-emacs@gnu.org; Mon, 30 Sep 2024 12:29:32 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1svJH8-0004wL-4I for bug-gnu-emacs@gnu.org; Mon, 30 Sep 2024 12:29:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=TYmALIn5V9K3kUPcaDN7Imx7EUHlqfxmBU7VshIpk4U=; b=fpEnaDnXbTbCt56+bjGVt9qaJ+NWCpVaF6/eSkJoB/RJMMnrW9rlFB7W6rAU7kW2Zn9mPNvPvMXUCNbU+IMnAhXI9nHCAVOkBeibwwXBeywj66dtUYts50EbEDo0ckl1KdND5ER8h7qv0WVCtraIfSulD4PssSTHNOrN4M+/HRVVRo0q3NUZrPt6EOGMIXCcDVFo9pnt6Wxo+LzM0t0fxLARgg6ngW+I18EOqajMXU/6v+pRAy/tJje7UBTpy5fhf95bAvnuJVqB/xBSjUnf5yzTxMr/d8naNkIL7w9zL3TOt1vhIJlQ7YTBHifuKclQSWitJhgwlcOphsQg5TBkCw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1svJHe-00029E-VJ for bug-gnu-emacs@gnu.org; Mon, 30 Sep 2024 12:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Sep 2024 16:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73559 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 73559-submit@debbugs.gnu.org id=B73559.17277137968225 (code B ref 73559); Mon, 30 Sep 2024 16:30:02 +0000 Original-Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 16:29:56 +0000 Original-Received: from localhost ([127.0.0.1]:45750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svJHX-00028b-OR for submit@debbugs.gnu.org; Mon, 30 Sep 2024 12:29:56 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58510) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svJHV-00028R-A7 for 73559@debbugs.gnu.org; Mon, 30 Sep 2024 12:29:54 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1svJGr-0004ui-QQ; Mon, 30 Sep 2024 12:29:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=TYmALIn5V9K3kUPcaDN7Imx7EUHlqfxmBU7VshIpk4U=; b=JQn+4JeiwZIV wwW+qEJQK+Xd+bRJT0jP75PqZi7eZcoCUVyvF4Totsbz/ZgfrXzOHd60eav4oms00k76/iEviGMS8 lY7igS/ApzCsduhM0w4gzqXUItgfHJhdtLXQPHjj14EQ3nWedfUEQafiYXeF9vSlILx+JW7zx6/rh vS7yM7DU/4NLO51zHcswBuFfa4y8XJe8eaUniRNHexyZqyhimRL1OoBsS3VqIBhl6Gx6utNky/nD1 EajQT5s5ApduQRty+KoQ0cEBHQ2mCzAOFBcE548WyGsy8lBUX+j/mpgIbxKO1GOoM1Lb7ZNcjCck9 3b3rwGaBavRdKlvehtKksQ==; In-Reply-To: (message from Daniel Colascione on Mon, 30 Sep 2024 08:51:27 -0700) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:292728 Archived-At: > Date: Mon, 30 Sep 2024 08:51:27 -0700 > From: Daniel Colascione > CC: luangruo@yahoo.com, 73559@debbugs.gnu.org > > >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? Yes, of course it is. What happens on MS-Windows in this case is that when the Emacs frame gets focus, we are sent the WM_SETFOCUS message. That causes us to add to the input queue (by using kbd_buffer_store_event) an input event whose event->kind is FOCUS_IN_EVENT. Immediately after that, I see read_char call kbd_buffer_get_event (via several intermediate calls), and the FOCUS_IN_EVENT is read and processed I wonder why this doesn't happen for NS. (But I know that the NS port uses some tricky code to process events, so I'm hardly surprised.) > 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? Yes, definitely. And AFAIU that should happen because we call read_char whenever we are idle. Maybe the NS version of pselect sleeps indefinitely or for too long if no keyboard keys are pressed? On other systems, any message from the window-system exits pselect, but maybe that doesn't happen on NS? Does having a frequently-expiring timer cause the focus-in events to be processed more timely, without your patch?