From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#73559: [PATCH] fix NS build focus-in event processing Date: Mon, 30 Sep 2024 10:05:09 -0700 Message-ID: <76FBB8E4-B403-45DF-BFCA-2DE48B05E7A6@dancol.org> References: <871q113lil.fsf@dancol.org> <86v7yd2wsi.fsf@gnu.org> <86h69x2lud.fsf@gnu.org> <86ed512jhm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5413"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: K-9 Mail for Android Cc: luangruo@yahoo.com, 73559@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 30 19:05:59 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 1svJqQ-0001EN-1w for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 30 Sep 2024 19:05:58 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1svJqB-0006CY-9T; Mon, 30 Sep 2024 13:05:43 -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 1svJq0-0006Bt-0G for bug-gnu-emacs@gnu.org; Mon, 30 Sep 2024 13:05:33 -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 1svJpx-0000vD-19 for bug-gnu-emacs@gnu.org; Mon, 30 Sep 2024 13:05:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:From:Date:To:Subject; bh=nV6DVnLjwlD4FBTduyv54OYg81oBpclXuaiYWP+QUts=; b=P2mapL3rPAB2u/JwhLpfvLaEHfiy3Q/rnSDaR+H/rvk1PTvFPT1nWyWG+0V7sz98AIaSW6HZvCJtMzw2c4nMcIK+LhI2VfYti7IvNCMATXrFLisNW7p2zEnO/Z+EbXEdxHvL/qrmD6nEQbXdFftuYlxfmShjYi6rzXeS9Cbf9qZpoK8Wf3qmSyc2VdoUVcNaHy5+krpKgLTas5GoH6SHfPh9hn0PgZk+px1dlUyN7gsuvIl97E8C/8ZlGweBWHBAGrY0L8OpFZv6twgW5s50PuMpPcVu6NFjnHizhyx3YYNQftU1Y8AfhNn5gKt5uliByxRuDVnd/6B8w+Prxp15sQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1svJqT-0006Yl-Ti for bug-gnu-emacs@gnu.org; Mon, 30 Sep 2024 13:06:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 30 Sep 2024 17:06:01 +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.172771594824985 (code B ref 73559); Mon, 30 Sep 2024 17:06:01 +0000 Original-Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 17:05:48 +0000 Original-Received: from localhost ([127.0.0.1]:45900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svJqF-0006Ue-RI for submit@debbugs.gnu.org; Mon, 30 Sep 2024 13:05:48 -0400 Original-Received: from dancol.org ([96.126.100.184]:40468) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svJqD-0006S0-GO for 73559@debbugs.gnu.org; Mon, 30 Sep 2024 13:05:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nV6DVnLjwlD4FBTduyv54OYg81oBpclXuaiYWP+QUts=; b=aGqXYK/493WXVcX/a6oVw3ySUq u0Mq5NEMgc7y61QO4tC7VCXaMu97dMvcn78uN6z66ucXHgNdLDJ5tSz0Aq63bBSk9boQ+TNhrpqUW DytrG5Yr/7LQsFNcOrYKeEibl5eX/8uImZkaxav7ebxRiUub2a1fOP/n5dO/Lxj2DFkKvAIARxINR V3NqmEd9JskybPn7pUalChBpBEayy33IvS4b5ZRqzp7pUzPHx0NEoCc+fQMGQNQX5mqXqpYMm+qfx R7FmMqgv5O3mVYrmRaFUsBDMJQ+NQK5GhhUwm/nttvjUMKBZnRJjPkHnH3hghofT4jEA0oMVLsxbg d0iOjLCQ==; Original-Received: from [2600:1010:b013:b584:0:5c:111:2701] (port=40540 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1svJpd-0004OA-1Z; Mon, 30 Sep 2024 13:05:10 -0400 In-Reply-To: <86ed512jhm.fsf@gnu.org> 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:292730 Archived-At: On September 30, 2024 9:29:09 AM PDT, Eli Zaretskii wrote= : >> Date: Mon, 30 Sep 2024 08:51:27 -0700 >> From: Daniel Colascione >> CC: luangruo@yahoo=2Ecom, 73559@debbugs=2Egnu=2Eorg >>=20 >> >That's not what I meant=2E kbd_buffer_store_event doesn't trigger >> >reading from the queue, AFAIU=2E 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=2E >>=20 >> Yes=2E So now imagine that Emacs is idle and not the focused window=2E = I command-tab to it=2E Now Emacs is the focused window=2E I would expect Em= acs to have run the functions in focus-in-hook by now, but it didn't, becau= se when we got focus, we queued the focus event but didn't wake up the main= thread to process it=2E Now I hit a key=2E Emacs wakes up, drains its even= t loop (firing off focus-in-hook functions), and processes my keystroke=2E = Isn't it correct for Emacs to run that hook immediately when it gets focus,= not some time after? > >Yes, of course it is=2E > >What happens on MS-Windows in this case is that when the Emacs frame >gets focus, we are sent the WM_SETFOCUS message=2E 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=2E 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=2E (But I know that the NS port >uses some tricky code to process events, so I'm hardly surprised=2E) > >> In general, I don't see why we'd wire it up such that the event queue c= an be non-empty and the main thread asleep indefinitely=2E If we have an ev= ent to process, then in all circumstances, we should process it, yes? > >Yes, definitely=2E And AFAIU that should happen because we call >read_char whenever we are idle=2E 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? It's not that the NS pselect waits too long=2E It's that it doesn't know t= o wake up=2E The focus event is delivered to Emacs by NS as a callback=2E U= nless that callback, one way or another, takes some action to wake up the e= vent loop, nothing gets processed=2E On Windows, we drain the event queue a= s 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=2E >Does having a frequently-expiring timer cause the focus-in events to >be processed more timely, without your patch? I'd imagine so, but haven't been able to test yet=2E