From unknown Fri Jun 20 18:01:38 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#73559 <73559@debbugs.gnu.org> To: bug#73559 <73559@debbugs.gnu.org> Subject: Status: [PATCH] fix NS build focus-in event processing Reply-To: bug#73559 <73559@debbugs.gnu.org> Date: Sat, 21 Jun 2025 01:01:38 +0000 retitle 73559 [PATCH] fix NS build focus-in event processing reassign 73559 emacs submitter 73559 Daniel Colascione severity 73559 normal tag 73559 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 29 23:29:23 2024 Received: (at submit) by debbugs.gnu.org; 30 Sep 2024 03:29:26 +0000 Received: from localhost ([127.0.0.1]:43969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sv765-0007bV-OU for submit@debbugs.gnu.org; Sun, 29 Sep 2024 23:29:22 -0400 Received: from lists.gnu.org ([209.51.188.17]:39610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sv75w-0007Zj-Ce for submit@debbugs.gnu.org; Sun, 29 Sep 2024 23:29:13 -0400 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 1sv75P-0004zI-To for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2024 23:28:35 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sv75N-0004nM-SP for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2024 23:28:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From:Sender: Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=BwVRwDR7UrrHHXs9XVCKtACSIFbaqFO2jrnCjHIBtq4=; b=gcJARsdRwfany5Zy3uB/iijW7d ekjVv8haLUxonQFRBUV0tG8Th4zVGbge9/ykK/usQjyYODImRoOG5207iiVGXeZ/EwgI6dy2uZNga pHpt6Xpo54IRC9CtVbHECfIXl78H0YSxCpSsRHfO5mY0nRa8GBF/Zje3vR+sH1VTBJoeeG9DGywls 3YFTQxqtC9Y6D78Gtcr8uqza7ScC3nx7cmeZkYpqPVzdOK0aTnQRXyAKwOXN5EntN+H0NuPN5G7FH g2qQApV8dRGVryigoUB6JxrfbytjcDpkYvaUwUd9tQ4X5J5T33Bvq8NT7kSFwj8FiM+OVDugjBPx5 tTVCW8eA==; Received: from [2600:3c01:e000:3d8:1::1001] (port=52208 helo=localhost) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1sv6S1-00010J-09 for bug-gnu-emacs@gnu.org; Sun, 29 Sep 2024 22:47:55 -0400 From: Daniel Colascione To: bug-gnu-emacs@gnu.org Subject: [PATCH] fix NS build focus-in event processing User-Agent: mu4e 1.12.6; emacs 31.0.50 Date: Sun, 29 Sep 2024 22:47:46 -0400 Message-ID: <871q113lil.fsf@dancol.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.1 (/) 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 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 } From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 30 03:37:01 2024 Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 07:37:01 +0000 Received: from localhost ([127.0.0.1]:44576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svAxh-0006iB-Ch for submit@debbugs.gnu.org; Mon, 30 Sep 2024 03:37:01 -0400 Received: from mail-lj1-f182.google.com ([209.85.208.182]:44428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svAwr-0006XP-Tt for 73559@debbugs.gnu.org; Mon, 30 Sep 2024 03:36:52 -0400 Received: by mail-lj1-f182.google.com with SMTP id 38308e7fff4ca-2fac47f0b1aso11598461fa.1 for <73559@debbugs.gnu.org>; Mon, 30 Sep 2024 00:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727681629; x=1728286429; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :from:to:cc:subject:date:message-id:reply-to; bh=sLKQdONuiX6LZDLRy6QrOjZIwQfP3d+6U8+SWd7B5Gs=; b=HOHW15+9uRPY52TjpmR0joZbE6th4mWjB2e4PDwrMhQAYk2iMBYQeM0x1xGgGbeAr3 oyYbrC+L9oc1EMetzXLu5BWNc6bHf4JHbfnf5iS/B+OiitQqyO29v0oNh2VVGpzv+5xj TqUfDjzii9D8huoRG15x8Rjlson+NDI/l/RMdpLe8wClVljpqWs2ZPPx/TueUaPbZmS9 j1YPCyvhjLYruEvgN/LGjJGtOz4Ac02yn87vw4RRzNXsY0Q2hE6GubQk1Mz0+hoP1pgz Pq6wZAF+UhbFKQppUD2jB78kkmwsmMPq+QUH9sQwl/6x9GRmDoXK/3d0ml6XOgREHyie sHzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727681629; x=1728286429; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sLKQdONuiX6LZDLRy6QrOjZIwQfP3d+6U8+SWd7B5Gs=; b=a4yUFViyLN0qX3y4G0onow18ywLcNlqlC/0g6DzUA7NHnv0ByHkP0s6n/ha5W/RSF4 jC69GFnpDeDrUHUjgbayEqbdF1+APuJlN7mJCmBXpij50xKBzlp75T5wbUE5XA0x3yKn 5ygFWryVL+iFSno5TnSkhyXu70IEjeD9W/x9yaS0+wNabHE2MacAhKPJpEF5TYo7IoBH n3xKU7VyhEcJRj81f5cJMiAQbyxuBUXdHEJFvUoky7GdKdSj6XPj63OvbDLS0LdgtOnv 46deLXlJyPDFm26dH16DneMSndSzKT11DzjySupvY91FxJ6bja3u8nzRCRi0xuIbWUag TCkA== X-Forwarded-Encrypted: i=1; AJvYcCVFPN8AASd5GnWhgIXWWJK94ZOmiVtmRtweNWyGvZrBSYAFRqGt5Er+01MSMbpTEK+P5QYUmQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzqxQsb68QBlqPoP0mMqkHZDxFE7q6AMxHFdAljyNwCFdO1v7M8 viAqj/eHdjFmouD76WowfODC0l6u0FNekAO2+BFA4spLKa9uoXvt5jUInVM0N3JRUbHLou+VhEi d2ULHs0uMwdkVedEWAE7MuvhqsRPGlA== X-Google-Smtp-Source: AGHT+IGo0+Vyyj+ON72DQt8iwnAB9I/Cu23JEYDBwOPycOefLhCDdUL/8H5gWAU8ejcimCr/IILSrvzmqGN6Juxl1IM= X-Received: by 2002:a2e:a591:0:b0:2f5:2e2:eaf9 with SMTP id 38308e7fff4ca-2f9d3e3c4a0mr53262671fa.4.1727679339105; Sun, 29 Sep 2024 23:55:39 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 29 Sep 2024 23:55:38 -0700 From: Stefan Kangas In-Reply-To: <871q113lil.fsf@dancol.org> References: <871q113lil.fsf@dancol.org> MIME-Version: 1.0 Date: Sun, 29 Sep 2024 23:55:38 -0700 Message-ID: Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing To: Daniel Colascione , 73559@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73559 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) Daniel Colascione writes: > 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. Thanks for the patch. Please always send patches as attachments if possible, as formatted by git format-patch -1 > commit c6d98bfc2a098b57fa9631978224ead2668d3a88 > Author: Daniel Colascione > 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 > } > > From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 30 07:45:10 2024 Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 11:45:10 +0000 Received: from localhost ([127.0.0.1]:44863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svEpw-0005ai-3U for submit@debbugs.gnu.org; Mon, 30 Sep 2024 07:45:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svEnh-0004t5-E2 for 73559@debbugs.gnu.org; Mon, 30 Sep 2024 07:43:23 -0400 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 1svEn4-0005w1-Mj; Mon, 30 Sep 2024 07:42:10 -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=K4QyrHp5+JYwnO9uLX4qBXXo19VTxSJxnlB5Uu/nX44=; b=SyBlG3u1t7tJ 2dJgSTQSsxytTffmmxligK03XJOyCptc4hGndhJITkmwjg/1D9GbE/neTDNRHTUIrRcAV6YFAUvta sh1Rs5wBiZcWHJJ6ir6nvFhfKyzqUqZnDFCwt/bzyK7NoiXxbwQZ+S0j1HBlKNzT9nR+rS800ekUN ndMKBUQS+C3wBnfv/etlDs/whLxDmx/bo48mHuw/vgK1lQAryrGfCCdCKIKuzZMrcvzC73dWGCRSL q9GPS1e9ShG78RfmtJWyFXrNPpURX7AdrwvN6ncPgC4uLC0bcKPlFmIaBx5JCbGkLyxcxVsK34EUJ ISF6WBcywkL4u3IlN/WV8A==; Date: Mon, 30 Sep 2024 14:41:49 +0300 Message-Id: <86v7yd2wsi.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione , Po Lu In-Reply-To: <871q113lil.fsf@dancol.org> (message from Daniel Colascione on Sun, 29 Sep 2024 22:47:46 -0400) Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing References: <871q113lil.fsf@dancol.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73559 Cc: 73559@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Daniel Colascione > 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. Hmm... isn't this the same on all other GUI systems? kbd_buffer_store_event adds the event to the Emacs input queue, and AFAIU it will be processed as soon as Emacs gets back to its main loop and calls read_char. No other event should be needed, AFAIK. Po Lu, am I missing something here? > 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. I know nothing about the "NS event loop", so I'm probably missing something. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 30 10:23:24 2024 Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 14:23:24 +0000 Received: from localhost ([127.0.0.1]:45169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svHJ6-0004rH-4J for submit@debbugs.gnu.org; Mon, 30 Sep 2024 10:23:24 -0400 Received: from dancol.org ([96.126.100.184]:43198) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svHJ2-0004rB-53 for 73559@debbugs.gnu.org; Mon, 30 Sep 2024 10:23:22 -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=p3n01+WgNwrtX5u5vKmkDLcmnMrk3XlKD7MQK/OGKCU=; b=MqsOM1Q0u/KIOfU1QimgDLNzRo ifYATargttY1NC9E2ey6z1ZK6pAheJQGOiZK8RBjP6af7UDMBLmTUIsPEMYKpJQRVze10cqP7AoHV w/WFSdg5JLdqQlvTBHXVDKCS3DXMqfrJfqN2dr7fLevHfAa88bk/JJzkrqN3QfGAcTUTbWIh8W9ai JFy9ZRXaclaxxHtiEv12A4rOxNjRU1Xuqh45ROGksPb2GEETLfI5dkypMttPvObTsLqha/dcKKUxW yBewyDQ8k/qzKNYGtj6X5/8zEqT/QDJUMae/S/Ms+YndEH562Mv4gdVsuawXSTblCzbZO0xB2VpwI V4d47vcg==; Received: from [12.51.135.7] (port=42880 helo=[127.0.0.1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1svHGG-0003gn-2p; Mon, 30 Sep 2024 10:20:29 -0400 Date: Mon, 30 Sep 2024 07:20:26 -0700 From: Daniel Colascione To: Eli Zaretskii , Po Lu Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing User-Agent: K-9 Mail for Android In-Reply-To: <86v7yd2wsi.fsf@gnu.org> References: <871q113lil.fsf@dancol.org> <86v7yd2wsi.fsf@gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73559 Cc: 73559@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On September 30, 2024 4:41:49 AM PDT, Eli Zaretskii wrote= : >> From: Daniel Colascione >> Date: Sun, 29 Sep 2024 22:47:46 -0400 >>=20 >>=20 >> In Emacs NS build, frames don't respond to focus-in events right away= =2E >> Instead, they store the focus-in event and process it (and other queued >> events) whenever some other event happens to occur on that frame=2E > >Hmm=2E=2E=2E isn't this the same on all other GUI systems? >kbd_buffer_store_event adds the event to the Emacs input queue, and >AFAIU it will be processed as soon as Emacs gets back to its main loop >and calls read_char=2E No other event should be needed, AFAIK=2E Po Lu, >am I missing something here? > >> This patch kicks the NS event loop immediately when a focus-in event >> happens, allowing Emacs to respond to focus-in events without some othe= r >> event triggering the processing=2E I don't recall what we do for other systems, but for NS, we don't wake up = the event loop as a side effect of kbd_buffer_store_event by itself=2E We r= ely on something else waking up the loop draining events from the queue=2E = Changing the kbd_buffer_store_to_event to wake the main thread unconditiona= lly would be another option, but seemed like a bigger change=2E > >I know nothing about the "NS event loop", so I'm probably missing >something=2E > >Thanks=2E From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 30 11:54:21 2024 Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 15:54:21 +0000 Received: from localhost ([127.0.0.1]:45587 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svIj7-0000jh-Dj for submit@debbugs.gnu.org; Mon, 30 Sep 2024 11:54:21 -0400 Received: from dancol.org ([96.126.100.184]:48202) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svIj4-0000jY-3h for 73559@debbugs.gnu.org; Mon, 30 Sep 2024 11:54:20 -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=CfY1pYAd/YzaIsVhs27ZDoW+mpW4Kvr2UH77ZPtMCPE=; b=YctxsoIrcSfFNdcDUUixEjFA6G PJ//sJIxLxWt3B0tDVRwp0jG8TceZPPP8qYf6VSnvnwynrluYEN79ZHR/TNfy2G7IuLPOnythecLA N2mizqY3g0L+lAuqMXrl7Pb+8+utgopwsOR5QsyqtpCevDAT1xhhOeDLQjFQxa6re0sgrLOMQopk5 pfmkJcMuW08eeo5uPxomDiXWCQoVSiMOELV7XQtExK4qHsmMnWnYhjAc3FGAuWQTSamwN6E37qJdG Etpk/JoR9OX1VeNLoXYHGczFCsPMcYfWqcuhJ5iC/ARX/iixYuE3ZnaOoy/1Uw0HZ+Mo7zBHd0yLF tDte0sYQ==; Received: from [2600:1010:b013:b584:0:5c:111:2701] (port=60082 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 1svIgJ-00045i-1i; Mon, 30 Sep 2024 11:51:28 -0400 Date: Mon, 30 Sep 2024 08:51:27 -0700 From: Daniel Colascione To: Eli Zaretskii Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing User-Agent: K-9 Mail for Android In-Reply-To: <86h69x2lud.fsf@gnu.org> References: <871q113lil.fsf@dancol.org> <86v7yd2wsi.fsf@gnu.org> <86h69x2lud.fsf@gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73559 Cc: luangruo@yahoo.com, 73559@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On September 30, 2024 8:38:18 AM PDT, Eli Zaretskii wrote= : >> Date: Mon, 30 Sep 2024 07:20:26 -0700 >> From: Daniel Colascione >> CC: 73559@debbugs=2Egnu=2Eorg >>=20 >>=20 >>=20 >> On September 30, 2024 4:41:49 AM PDT, Eli Zaretskii wr= ote: >> >> From: Daniel Colascione >> >> Date: Sun, 29 Sep 2024 22:47:46 -0400 >> >>=20 >> >>=20 >> >> In Emacs NS build, frames don't respond to focus-in events right awa= y=2E >> >> Instead, they store the focus-in event and process it (and other que= ued >> >> events) whenever some other event happens to occur on that frame=2E >> > >> >Hmm=2E=2E=2E isn't this the same on all other GUI systems? >> >kbd_buffer_store_event adds the event to the Emacs input queue, and >> >AFAIU it will be processed as soon as Emacs gets back to its main loop >> >and calls read_char=2E No other event should be needed, AFAIK=2E Po = Lu, >> >am I missing something here? >> > >> >> This patch kicks the NS event loop immediately when a focus-in event >> >> happens, allowing Emacs to respond to focus-in events without some o= ther >> >> event triggering the processing=2E >>=20 >> I don't recall what we do for other systems, but for NS, we don't wake = up the event loop as a side effect of kbd_buffer_store_event by itself=2E W= e rely on something else waking up the loop draining events from the queue= =2E Changing the kbd_buffer_store_to_event to wake the main thread uncondit= ionally would be another option, but seemed like a bigger change=2E > >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 Yes=2E So now imagine that Emacs is idle and not the focused window=2E I c= ommand-tab to it=2E Now Emacs is the focused window=2E 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 th= read to process it=2E Now I hit a key=2E Emacs wakes up, drains its event l= oop (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, no= t some time after? 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=2E If we have an event= to process, then in all circumstances, we should process it, yes? From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 30 11:57:23 2024 Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 15:57:23 +0000 Received: from localhost ([127.0.0.1]:45605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svIm3-0000tt-5q for submit@debbugs.gnu.org; Mon, 30 Sep 2024 11:57:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svIUH-0006v3-Vp for 73559@debbugs.gnu.org; Mon, 30 Sep 2024 11:39:54 -0400 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 1svITd-0007jo-Pt; Mon, 30 Sep 2024 11:38:21 -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=UdQW3UnXMXvTSeilMm7ltI9Zu9aJMA9tEYSDFrjCqmw=; b=F5wIzimcejMX ZhbBc9PpilXYJs3bE802TsqjayDFOwils4HWUBklELxNRlJFLyOOjSIjw5VIVOKW4czh2YTCOpxj6 jsp2zMy94Co52z58WuLxVZioHWavZTcOqBvq+q33DInLY5wH/CgCcxiI2A1UnzKHeFECJSf7i1joA 9KKMfNhUa7PyoZO4QWeR4t8MbMwJZbY6rmvkMifV8w8bqhgUUId90Z8tPkNkmyF6gJpUWrv7755KG /cuUP5ibRj5DtqC5rqGM9DQcbNjAg4SJ+U3aCkZtp2HB/xX7j2kSIiwUSJDvSnfKVTL0jfDuJolKE UVfbJMhKVWOhU9Cy3ve9vw==; Date: Mon, 30 Sep 2024 18:38:18 +0300 Message-Id: <86h69x2lud.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: (message from Daniel Colascione on Mon, 30 Sep 2024 07:20:26 -0700) Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing References: <871q113lil.fsf@dancol.org> <86v7yd2wsi.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73559 Cc: luangruo@yahoo.com, 73559@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Date: Mon, 30 Sep 2024 07:20:26 -0700 > From: Daniel Colascione > CC: 73559@debbugs.gnu.org > > > > On September 30, 2024 4:41:49 AM PDT, Eli Zaretskii wrote: > >> From: Daniel Colascione > >> 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. > > > >Hmm... isn't this the same on all other GUI systems? > >kbd_buffer_store_event adds the event to the Emacs input queue, and > >AFAIU it will be processed as soon as Emacs gets back to its main loop > >and calls read_char. No other event should be needed, AFAIK. Po Lu, > >am I missing something here? > > > >> 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. > > I don't recall what we do for other systems, but for NS, we don't wake up the event loop as a side effect of kbd_buffer_store_event by itself. We rely on something else waking up the loop draining events from the queue. Changing the kbd_buffer_store_to_event to wake the main thread unconditionally would be another option, but seemed like a bigger change. 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 30 12:29:56 2024 Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 16:29:56 +0000 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 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 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==; Date: Mon, 30 Sep 2024 19:29:09 +0300 Message-Id: <86ed512jhm.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: (message from Daniel Colascione on Mon, 30 Sep 2024 08:51:27 -0700) Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing References: <871q113lil.fsf@dancol.org> <86v7yd2wsi.fsf@gnu.org> <86h69x2lud.fsf@gnu.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73559 Cc: luangruo@yahoo.com, 73559@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > 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? From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 30 13:05:48 2024 Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 17:05:48 +0000 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 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==; 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 Date: Mon, 30 Sep 2024 10:05:09 -0700 From: Daniel Colascione To: Eli Zaretskii Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing User-Agent: K-9 Mail for Android In-Reply-To: <86ed512jhm.fsf@gnu.org> References: <871q113lil.fsf@dancol.org> <86v7yd2wsi.fsf@gnu.org> <86h69x2lud.fsf@gnu.org> <86ed512jhm.fsf@gnu.org> Message-ID: <76FBB8E4-B403-45DF-BFCA-2DE48B05E7A6@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73559 Cc: luangruo@yahoo.com, 73559@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 30 13:53:55 2024 Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 17:53:56 +0000 Received: from localhost ([127.0.0.1]:46098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svKak-0003QM-Hf for submit@debbugs.gnu.org; Mon, 30 Sep 2024 13:53:55 -0400 Received: from dancol.org ([96.126.100.184]:34304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svKaI-0003L8-Cq for 73559@debbugs.gnu.org; Mon, 30 Sep 2024 13:53:45 -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=ulLLh6dMUtODvTZAxvJXTgYmQ4/7DISHF3vgOBGs2ZI=; b=FucVAlp+Vyy66gvtP/sojtS7GZ 7eZYoOJ+wHAHdzmMPLV5d8luLnDvy1K6qhwsXfQJ/lbLP1HsMiRXPWzMKCWAyLGFmZIY5bEZ9irCL hdUTsn7J+xVX7aJ5SvU9qH/aBTJ80LxOu++XSIlLpw8WTnOB1oXCftMlaCTvIHBL049ZWXAiFNPAA JXIJGhESXNh1lnCZ+P5hZRshT/7Sp8mqc5+mah2zTTHwV0uZ3lhUdfxe/eBLy2Ccj5VOE9ljoBZNv V/CN1q/eRi1ofKCLUGLETtIFHQxu8vYgND7dH44VOWlRBp1opZ7U/3hdFHP2VVAb/nhSmAJgAvAFA kTCwOiDg==; Received: from [2600:1010:b013:b584:0:5c:111:2701] (port=37436 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 1svKXX-0004ZF-1O; Mon, 30 Sep 2024 13:50:32 -0400 Date: Mon, 30 Sep 2024 10:50:31 -0700 From: Daniel Colascione To: Eli Zaretskii Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing User-Agent: K-9 Mail for Android In-Reply-To: <86bk052g5y.fsf@gnu.org> References: <871q113lil.fsf@dancol.org> <86v7yd2wsi.fsf@gnu.org> <86h69x2lud.fsf@gnu.org> <86ed512jhm.fsf@gnu.org> <76FBB8E4-B403-45DF-BFCA-2DE48B05E7A6@dancol.org> <86bk052g5y.fsf@gnu.org> Message-ID: <5DE09C90-164F-47B0-A752-F20C9AC82034@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73559 Cc: luangruo@yahoo.com, 73559@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On September 30, 2024 10:40:57 AM PDT, Eli Zaretskii wrot= e: >> Date: Mon, 30 Sep 2024 10:05:09 -0700 >> From: Daniel Colascione >> CC: luangruo@yahoo=2Ecom, 73559@debbugs=2Egnu=2Eorg >>=20 >> It's not that the NS pselect waits too long=2E It's that it doesn't kno= w to wake up=2E The focus event is delivered to Emacs by NS as a callback= =2E Unless that callback, one way or another, takes some action to wake up = the event loop, nothing gets processed=2E On Windows, we drain the event qu= eue 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=2E > >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=2E My patch just uses th= e existing machinery for waking the main thread instead of adding a new FD= =2E From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 30 14:04:27 2024 Received: (at 73559) by debbugs.gnu.org; 30 Sep 2024 18:04:27 +0000 Received: from localhost ([127.0.0.1]:46145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svKky-0004Sh-4R for submit@debbugs.gnu.org; Mon, 30 Sep 2024 14:04:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58588) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svKkw-0004SW-1b for 73559@debbugs.gnu.org; Mon, 30 Sep 2024 14:04:22 -0400 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 1svKOO-0005NI-Nz; Mon, 30 Sep 2024 13:41:04 -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=699H3Yu69bWFGFu/ZchV2c3AdJF+YtNrCE8cN1jgflI=; b=bETW9FFEp07n r1TTlKWyqTNP9H2vgAmSlNMIh8YORuPMDZw0Idyr7Pf0hZTxOOGzj9b9F1ZVNf3WBnuoXCHc1r3v8 pvDDQ9ONPyO32trJCmWMlBhqXQMx+OCzVgeXTwBQNv2ny4xuquZ7X9W3bFsgGZqNJN/7/wsbJk11S KUnW3eEgpI2NHB2FsUVrXc1bhIMMp5VFVhJWSwsQ8MUVqmL6TEEY1Gn/uJbbp/GLQkRGgBG9L+bxM HCk3ebCWHMK8QEqoeqhNezZz3HW6mZQTBfZmEBKUE38LQUZpum/kUeMhx8744TIO1AjwU7Kv5VPJ7 SZhSU+AfUGPlRRJxu1Pk9g==; Date: Mon, 30 Sep 2024 20:40:57 +0300 Message-Id: <86bk052g5y.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: <76FBB8E4-B403-45DF-BFCA-2DE48B05E7A6@dancol.org> (message from Daniel Colascione on Mon, 30 Sep 2024 10:05:09 -0700) Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing References: <871q113lil.fsf@dancol.org> <86v7yd2wsi.fsf@gnu.org> <86h69x2lud.fsf@gnu.org> <86ed512jhm.fsf@gnu.org> <76FBB8E4-B403-45DF-BFCA-2DE48B05E7A6@dancol.org> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 73559 Cc: luangruo@yahoo.com, 73559@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Date: Mon, 30 Sep 2024 10:05:09 -0700 > From: Daniel Colascione > CC: luangruo@yahoo.com, 73559@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? From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 05 06:37:28 2024 Received: (at 73559-done) by debbugs.gnu.org; 5 Oct 2024 10:37:28 +0000 Received: from localhost ([127.0.0.1]:37351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sx2AC-0006YA-El for submit@debbugs.gnu.org; Sat, 05 Oct 2024 06:37:28 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sx2AB-0006Xy-21 for 73559-done@debbugs.gnu.org; Sat, 05 Oct 2024 06:37:27 -0400 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 1sx2A0-0003op-Ph; Sat, 05 Oct 2024 06:37:16 -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=E97r8K+Wq9Aln+UhkYfUSh59sVIJI1eQqrIRw3xa4OU=; b=TLca0cN1/Hdh yzQA8l+ZqgZsOlXBQZzxWcSO8BcCAapkK0i4UDFBs4HZy+vY++ziWOExvSXuYPxtxzrB3P1QTQ1hY JrKcZMqf3qElT/kc7T1Ojd1HvkXYqkHIhm8vjT1D5O762N8HvCyxfNJJ7XnMKePyApIh8D6clzKc2 2thbUMIELCFMDbN3mPRC0FpMqV4KPvn3YTkRlYSbjXoZQ9nVLWEJjS5FyklZlS3n4p+5Rpn/mK74O 4y1GcHxZr6Zghd0PFSTFEBiu05CU/rT5E64wqH1t8h74NbohiLO0Ho19/gWB9pyD0VzTcxr3/r/ME /kMsmeA8KsNAMSdmKfjPdQ==; Date: Sat, 05 Oct 2024 13:37:14 +0300 Message-Id: <86iku6x2cl.fsf@gnu.org> From: Eli Zaretskii To: Daniel Colascione In-Reply-To: <5DE09C90-164F-47B0-A752-F20C9AC82034@dancol.org> (message from Daniel Colascione on Mon, 30 Sep 2024 10:50:31 -0700) Subject: Re: bug#73559: [PATCH] fix NS build focus-in event processing References: <871q113lil.fsf@dancol.org> <86v7yd2wsi.fsf@gnu.org> <86h69x2lud.fsf@gnu.org> <86ed512jhm.fsf@gnu.org> <76FBB8E4-B403-45DF-BFCA-2DE48B05E7A6@dancol.org> <86bk052g5y.fsf@gnu.org> <5DE09C90-164F-47B0-A752-F20C9AC82034@dancol.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 73559-done Cc: luangruo@yahoo.com, 73559-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 30 Sep 2024 10:50:31 -0700 > From: Daniel Colascione > CC: luangruo@yahoo.com, 73559@debbugs.gnu.org > > > > On September 30, 2024 10:40:57 AM PDT, Eli Zaretskii wrote: > >> Date: Mon, 30 Sep 2024 10:05:09 -0700 > >> From: Daniel Colascione > >> CC: luangruo@yahoo.com, 73559@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. From unknown Fri Jun 20 18:01:38 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 02 Nov 2024 11:24:14 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator