From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Jun 2025 20:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 78737@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.17495021663966 (code B ref -1); Mon, 09 Jun 2025 20:50:02 +0000 Received: (at submit) by debbugs.gnu.org; 9 Jun 2025 20:49:26 +0000 Received: from localhost ([127.0.0.1]:58095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOjQr-00011r-Ot for submit@debbugs.gnu.org; Mon, 09 Jun 2025 16:49:26 -0400 Received: from lists.gnu.org ([2001:470:142::17]:50394) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOjQp-0000yY-Bh for submit@debbugs.gnu.org; Mon, 09 Jun 2025 16:49:23 -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 1uOjQY-0003XT-Me for bug-gnu-emacs@gnu.org; Mon, 09 Jun 2025 16:49:07 -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 1uOjQW-0003YV-Ky for bug-gnu-emacs@gnu.org; Mon, 09 Jun 2025 16:49:06 -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=LYh9uG1Ppvq8J3xrTikNHmqEs/90Nm5HbZJs1ZKn77Y=; b=nnQ6rygK2b4d9ErHwjiwRpW1c4 zIm3yST3ktIL3UcgXwKcKEkiZniyxtVeDAXCgIpcO72tJ+6+G7lmkRlYh2M9a73FbwRa/zhpVsYRd ySZpCVMk/JEGwSUFOuKjcOb2TAbIaxuoeK3pyzvtsZbgUCf02kojkZWkMU22iI1EKVSO/Tk0k1jpt UJJLtnl8q57YHbSfB7RG+iPcBiGSLtPM5MKVK32PtVAN/GwUiFdOtuXlJ6DP4uyLJ4MZoUm7YEwrW ZQm8vSPbss46+Me11e6lm4XpTd/RVSUBOflK95c/6ERoIarUmyqty7slhElu4WHBq06qKdP0w4O1N V7Ac3WlA==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uOjPB-00BSim-1D for bug-gnu-emacs@gnu.org; Mon, 09 Jun 2025 16:47:41 -0400 From: Daniel Colascione User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Mon, 09 Jun 2025 13:48:59 -0700 Message-ID: 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-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 (/) Consider (while-no-input (sit-for 100)). Run it and press any key, say, f to terminate the wait. You'll see "f" inserted wherever point was. Now eval-defun on sit-for from subr.el and try (while-no-input (sit-for 100)) again. The "f" disappears. Why? Because Fread_event returns with Vquit_flag set; the byte-compiled sit-for is able to push the event onto Vunread_command_events before Lisp does something quit-able, but the interpreted sit-for doesn't get so far and loses Fread_event's return value. Fread_event should probably look for Vquit_flag and !Vinhibit_quit and in this case stick the event on Vunread_command_events itself and return nil. WDYT? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 09:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174954680723744 (code B ref 78737); Tue, 10 Jun 2025 09:14:01 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 09:13:27 +0000 Received: from localhost ([127.0.0.1]:34396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOv2s-0006Au-IF for submit@debbugs.gnu.org; Tue, 10 Jun 2025 05:13:26 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:23729) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOv2j-00069m-Gd for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 05:13:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749546790; x=1749805990; bh=C6q84/jFh/H9e8cgXfCLAnMYCxuoPPUnN9puaYG9MX0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=Zz/Ge/8C26w25fSWJLSngGPxoPNmcT5FwNBRP2yMGk3lkopmE6/sxlS2f2qsf7NIi 31faZyiWubW8GQrDCYJ/BTuzSoetA823X5MrDuRv6BgygxkKE+ovzxOoVIzVpb/OY1 gYP+zrEZPsVyreLhIES6VmGuFJxEK6P/0xDwPfYkdoesZWIEpCusEaNW7AC8iXsCqz mjKqJO+hWu8vw1zc+alTTYtqHdf5zojhXlTFgYWeyaZp0cbNe2nmu8MR0b1U6NJZmB SoVEgXw3OEnG2IqsfDPGYedBo7YFyhDFFOE4vZHAw1hXA1j5iHEMTbBIClN/Dc3Ca7 Liz2nz/O7ulmA== Date: Tue, 10 Jun 2025 09:13:03 +0000 From: Pip Cet Message-ID: <87ikl42c4l.fsf@protonmail.com> In-Reply-To: References: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 05cd1257ea29df1feb76361920368c043d213ea5 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Daniel Colascione" writes: > Consider (while-no-input (sit-for 100)). > > Run it and press any key, say, f to terminate the wait. You'll see "f" > inserted wherever point was. > > Now eval-defun on sit-for from subr.el and try (while-no-input (sit-for > 100)) again. The "f" disappears. > > Why? Because Fread_event returns with Vquit_flag set; the byte-compiled > sit-for is able to push the event onto Vunread_command_events before > Lisp does something quit-able, but the interpreted sit-for doesn't get > so far and loses Fread_event's return value. > > Fread_event should probably look for Vquit_flag and !Vinhibit_quit and > in this case stick the event on Vunread_command_events itself and > return nil. Until we fix sit-for by adding a mechanism to peek at rather than read and dequeue input events, would it be sufficient just to bind inhibit-quit while reading and unreading the event? It appears to work, at least. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 09:33:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17495479822295 (code B ref 78737); Tue, 10 Jun 2025 09:33:05 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 09:33:02 +0000 Received: from localhost ([127.0.0.1]:34507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOvLn-0000ae-Ax for submit@debbugs.gnu.org; Tue, 10 Jun 2025 05:33:01 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:60594) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOvLh-0000ZV-Gh for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 05:32:56 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=xtEV3en2JINx75vSVnnlCRjT3EqUmTMGSgKc/FYt1IE=; b=opy6nHX68Ybki082/bTFerXiQ8 HNLDkLsevC6DGqQUz2lk4HWG4FSKeY3Py7AzNbcg109zPNgbUIuZOCcwJDlJ8RT2ebak7RMOI7JnJ +9JeBU1mtrkwDM+UiCA8dNCaSfng2qV7B8eMkXbl8yAUSGIoaNr3JP7OPCEZGWnQV9qbmOBfERk1s YPWuSXWMrQbJVu1fR9YHkrir6WAMWdsobg7MUwaWp1GNm4l9k+xXb6udsbTbknBHuvDucyFwcdNSN labemfXa3qNBUr/lo8OmVN+g59qWLiL9eDJrKgVHK5gc6LmgRGV+GqMmnaOnZZMFDvev1J5Jg0Bad smRz7k/Q==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uOvKN-00BWvY-15; Tue, 10 Jun 2025 05:31:31 -0400 From: Daniel Colascione In-Reply-To: <87ikl42c4l.fsf@protonmail.com> References: <87ikl42c4l.fsf@protonmail.com> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Tue, 10 Jun 2025 02:32:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Pip Cet writes: > "Daniel Colascione" writes: > >> Consider (while-no-input (sit-for 100)). >> >> Run it and press any key, say, f to terminate the wait. You'll see "f" >> inserted wherever point was. >> >> Now eval-defun on sit-for from subr.el and try (while-no-input (sit-for >> 100)) again. The "f" disappears. >> >> Why? Because Fread_event returns with Vquit_flag set; the byte-compiled >> sit-for is able to push the event onto Vunread_command_events before >> Lisp does something quit-able, but the interpreted sit-for doesn't get >> so far and loses Fread_event's return value. >> >> Fread_event should probably look for Vquit_flag and !Vinhibit_quit and >> in this case stick the event on Vunread_command_events itself and >> return nil. > > Until we fix sit-for by adding a mechanism to peek at rather than read > and dequeue input events, would it be sufficient just to bind > inhibit-quit while reading and unreading the event? It appears to work, > at least. And the other callers of read-event? Might as well just fix it at the source. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 11:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione , Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174955343614326 (code B ref 78737); Tue, 10 Jun 2025 11:04:01 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 11:03:56 +0000 Received: from localhost ([127.0.0.1]:35438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOwln-0003j0-WE for submit@debbugs.gnu.org; Tue, 10 Jun 2025 07:03:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45922) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOwlk-0003iV-RJ for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 07:03:53 -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 1uOwle-0002vI-N9; Tue, 10 Jun 2025 07:03:46 -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=lec69N3KcQaJfOVXQYZQiv6DszmXsC1ZIwkCVxaGdcA=; b=G1vXXPK3xhre 0p1+IuZbL0Na08VU/t9oxpfFVB6aZpDk8iVUy9E6WeewRqp+8mih/D54FygmS1mhtfu6anHw+kz9Q V120z1GWzMKzCXM07Jwpqz9r0siZjsNCZZVCmQHAKidoUFaKzCyIZvk9VyanRd1/ybhzo6M6927la yA+1zb2mg8gL7Qh0r1r1ziADCkBZQ5Hs+lPitpi2auoEs7lClmvmEWqHzmO/hKexkdVkjMNsVaIBS XlRuNd0cuot+d+GK2PsVQO81xEYFjTP3vJ8n6RKvAhpZH4EFvSsHIbbSbsWWvfdw10qHhQ9LA13LM Q6NTYADlTRlzTWHtEG3GKw==; Date: Tue, 10 Jun 2025 14:03:22 +0300 Message-Id: <86jz5jg8p1.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Tue, 10 Jun 2025 02:32:50 -0700) References: <87ikl42c4l.fsf@protonmail.com> X-Spam-Score: -2.3 (--) 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 (---) > Cc: 78737@debbugs.gnu.org > From: Daniel Colascione > Date: Tue, 10 Jun 2025 02:32:50 -0700 > > Pip Cet writes: > > > "Daniel Colascione" writes: > > > >> Consider (while-no-input (sit-for 100)). > >> > >> Run it and press any key, say, f to terminate the wait. You'll see "f" > >> inserted wherever point was. > >> > >> Now eval-defun on sit-for from subr.el and try (while-no-input (sit-for > >> 100)) again. The "f" disappears. > >> > >> Why? Because Fread_event returns with Vquit_flag set; the byte-compiled > >> sit-for is able to push the event onto Vunread_command_events before > >> Lisp does something quit-able, but the interpreted sit-for doesn't get > >> so far and loses Fread_event's return value. > >> > >> Fread_event should probably look for Vquit_flag and !Vinhibit_quit and > >> in this case stick the event on Vunread_command_events itself and > >> return nil. > > > > Until we fix sit-for by adding a mechanism to peek at rather than read > > and dequeue input events, would it be sufficient just to bind > > inhibit-quit while reading and unreading the event? It appears to work, > > at least. > > And the other callers of read-event? Might as well just fix it at the source. Stefan, any comments or suggestions? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 11:23:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, Daniel Colascione Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174955457719918 (code B ref 78737); Tue, 10 Jun 2025 11:23:03 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 11:22:57 +0000 Received: from localhost ([127.0.0.1]:35776 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uOx4D-0005BB-8R for submit@debbugs.gnu.org; Tue, 10 Jun 2025 07:22:57 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10558) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uOx4A-0005At-K0 for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 07:22:54 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0362810006B; Tue, 10 Jun 2025 07:22:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749554562; bh=yQdnp+u9p3mtCeIEPmXVMYUbUn2pCkChAlpaZhNNrzY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=AqEVlogCg6DGn60AkuT72MU2quFfhgI7+DQ5ZdgXQt+3T5JKf21Drf0k2pCPiewK+ HDseFJjUfTErl5Lekl2YNy0oIqGlAKASPeUcvVZlKSPgvTbOuJ53LAChFsgmY9TC8F UIEMgRuEHc3T4w+W/iD8HkYojLXqHS4eqHzc6JhkbsPaW3y0lGhvzcqydx/d6MQpa/ 9AWAJo2/dXZStrdugSM47HWfNr8H6204HVS7yHzFDdFqGMQ1qeQ83/lghtEOUlZ2AE 2ir7HqIixlJlvUTQ4WSxq5kxmxvq/k4ka1X/qGXveKkRqa38M62Mp0f19a7osLeEFB b1Q0nF9dwidxQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BB0FD100029; Tue, 10 Jun 2025 07:22:42 -0400 (EDT) Received: from asado (unknown [130.159.222.66]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 44C67120642; Tue, 10 Jun 2025 07:22:41 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86jz5jg8p1.fsf@gnu.org> Message-ID: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> Date: Tue, 10 Jun 2025 07:22:38 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> > Until we fix sit-for by adding a mechanism to peek at rather than read >> > and dequeue input events, would it be sufficient just to bind >> > inhibit-quit while reading and unreading the event? It appears to work, >> > at least. >> >> And the other callers of read-event? Might as well just fix it at the source. > > Stefan, any comments or suggestions? As Pip says, it would be nice to have way to peek rather than read+unread (the reason we don't AFAIK is that we don't just want to peek at the next event but at "some" next event while ignoring presumably irrelevant others, like mouse movements, so it's a bit less trivial than it sounds). Our handling of `inhibit-quit` is not very systematic, right now (and we've recently seen some of the impact, with the patch for `transient.el`). E.g. it's bound while running timers but not while running jit-lock code. It's never really clear why it's done at one place and not at others. Maybe doing it whenever we're waiting for user input (i.e. in `read_char`), like Daniel suggests, is not a bad idea and might be closer to The Right Way to use `inhibit-quit`. But then we need to make sure that when `read_char` returns a quit event, the caller eventually acts on this event. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 15:08:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17495680246019 (code B ref 78737); Tue, 10 Jun 2025 15:08:05 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 15:07:04 +0000 Received: from localhost ([127.0.0.1]:39152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP0Z4-0001YS-2E for submit@debbugs.gnu.org; Tue, 10 Jun 2025 11:07:04 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:47594) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP0Z0-0001Xg-HR for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 11:06:59 -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=5m0G9mzv2jZZCw1ZOjVaxYS+tvDe+99WUGSjXpPDxgE=; b=QMnnu0ZV2u1qZhcWW2KB6Txb3B 259TY4K0aj81qM15mTwZo9sYnbDKTtyQnXvjui+YdgogypJOgwG6j6XMJxl1mKk76PuvU0x4JsfwU nqXImwV5IUEetmcFQz+IcThxrtVfndSshPfXUZ/ZyGXWlLMuSZBiZpHuLJV4SWG3/NCyfaeND7kdL Le4jR+1yGZugSglPFl60EM1ou2GaaXnT2vmc/BcoJmkOidFVdbGRpJyQ/Rdo/V7otMXGct4AqP1qq GnN4sXi23rWoRrseTX4QtBnN65JL+UjZ3rrtHuryCfFrUOnzQgsuKizTx44tXq+2DHMPuj1ZKLFNU U/LkniqA==; Received: from [2600:1010:b044:9528:0:4e:46fb:1201] (port=53646 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 1uP0XX-00BXkb-1h; Tue, 10 Jun 2025 11:05:27 -0400 Date: Tue, 10 Jun 2025 08:06:46 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.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-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 June 10, 2025 4:22:38 AM PDT, Stefan Monnier wrote: >>> > Until we fix sit-for by adding a mechanism to peek at rather than re= ad >>> > and dequeue input events, would it be sufficient just to bind >>> > inhibit-quit while reading and unreading the event? It appears to w= ork, >>> > at least=2E >>>=20 >>> And the other callers of read-event? Might as well just fix it at the= source=2E >> >> Stefan, any comments or suggestions? > >As Pip says, it would be nice to have way to peek rather than >read+unread (the reason we don't AFAIK is that we don't just want to >peek at the next event but at "some" next event while ignoring >presumably irrelevant others, like mouse movements, so it's a bit less >trivial than it sounds)=2E > >Our handling of `inhibit-quit` is not very systematic, right now (and >we've recently seen some of the impact, with the patch for >`transient=2Eel`)=2E E=2Eg=2E it's bound while running timers but not wh= ile >running jit-lock code=2E It's never really clear why it's done at one >place and not at others=2E The disappearing C-g problem? The right fix for the transient=2Eel thing is not to randomly bind inhibit= -quit around swaths of user code, but to make sure event reading functions = return quit_char when the user presses them, just like we've documented rea= d-key-sequence to do=2E=20 IOW, C-g in the command loop can mean cmderror or does it mean C-g=2E How = do you know? Roll the dice=2E The user cannot predict whether redisplay is = going to run at the exact moment he whacks a key=2E This particular aspect = of the system has been ambiguous for a long time (ever since redisplay got = the ability to run Lisp?) and ultimately comes from C-g being overloaded in= the first place=2E That's *not* the same as just binding inhibit-quit around reading events l= ike transient tries to do=2E The problem with binding inhibit-quit is that,= well, you can't quit=2E Quitting restartable things that tend to get wedge= d like redisplay is useful=2E Instead, the event reading functions should i= nternally translate quits=2Eto quit_char returns even if a quit happened in= ternally=2E And they definitely shouldn't return with quit-flag set=2E This way, you can quit things that are useful to quit and not muck with th= ings that aren't=2E Binding inhibit-quit around timers and filters remain u= seful because those aren't idempotent=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 15:57:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17495709968758 (code B ref 78737); Tue, 10 Jun 2025 15:57:03 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 15:56:36 +0000 Received: from localhost ([127.0.0.1]:39265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP1L0-0002Gt-E6 for submit@debbugs.gnu.org; Tue, 10 Jun 2025 11:56:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42598) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP1Kx-0002FN-I1 for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 11:56:32 -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 1uP1Kr-00089i-7u; Tue, 10 Jun 2025 11:56:25 -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=Gx/4MEPaK7ec9T1xFJbX10uiTTwCNYAp/lswtCqf87o=; b=f//wmkXTGJTx tspjE00uiU61QX1uc/yuNKVGnfC3FP15yJQyuneRpYKocHn8BAMawMq0AcuI5v4NZ790zPc78khhN TKuBdUxzIERLb2wztt5u+tS0VfhccUb0VR0qWzO55UWamRkST4vx/W90dbEEcanSvaC0CvKMi8B77 SzLwSFKAx408gnkG6qd0f3FYF2vDHFTcSY3mcD8YLUZJeoZk/svGuPjsuwKQM+N1d7CqTMWyB5OGU Q1Ez5AkTPcJKHcys4UdWk75U5k2GLTlYB+h9E6/hbtzhG2JyVO7KuOVuvK9j0CHgzr++ba7bLoMiu qX6F2KFZ9FiKBrJatrIQ3Q==; Date: Tue, 10 Jun 2025 18:56:22 +0300 Message-Id: <8634c7fv4p.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Tue, 10 Jun 2025 08:06:46 -0700) References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Tue, 10 Jun 2025 08:06:46 -0700 > From: Daniel Colascione > CC: pipcet@protonmail.com, 78737@debbugs.gnu.org > > IOW, C-g in the command loop can mean cmderror or does it mean C-g. How do you know? Roll the dice. The user cannot predict whether redisplay is going to run at the exact moment he whacks a key. This particular aspect of the system has been ambiguous for a long time (ever since redisplay got the ability to run Lisp?) and ultimately comes from C-g being overloaded in the first place. First, redisplay is not part of the command loop, at least not conceptually: when redisplay runs, we don't respond to user input. And second, where we call Lisp from redisplay and cannot tolerate C-g (or don't think it would be useful), we bind inhibit-quit already. So I don't think I follow what you are saying here. > That's *not* the same as just binding inhibit-quit around reading events like transient tries to do. The problem with binding inhibit-quit is that, well, you can't quit. Quitting restartable things that tend to get wedged like redisplay is useful. It might be useful in principle, but if you allow that, you'll have an infinite redisplay loop on your hands. Why? because quitting has the side effect of showing "Quit" in the echo area, which re-enters redisplay right away, and will then wedge the same way as the one from which you wanted to escape. And second, because it isn't restartable. So aborting redisplay is tricky at best. We have an optional feature, by default off, which does that, see max-redisplay-ticks. If you follow how this is implemented when we decide to abort, you will see it isn't simple. And my personal experience from using this is that sometimes you are left with a partially-redrawn screen that you (as the user) don't always know how to fix. > Instead, the event reading functions should internally translate quits.to quit_char returns even if a quit happened internally. And they definitely shouldn't return with quit-flag set. How can this support breaking out of a runaway synchronous subprocess? Or any of the similar situations which today we can interrupt with a C-g? are we going to give up on them? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 16:23:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174957253726168 (code B ref 78737); Tue, 10 Jun 2025 16:23:05 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 16:22:17 +0000 Received: from localhost ([127.0.0.1]:39302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP1jo-0006nP-94 for submit@debbugs.gnu.org; Tue, 10 Jun 2025 12:22:16 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:55776) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP1jh-0006mE-Vc for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 12:22:09 -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=1wPh5Vk4l9gHpyJWaUFw19M/rbIWRjU5oxhMzrKv6vA=; b=T8ui0GeW8mcUXfF3fHWN71XL1a YUyDs9MPW69wU0J8N8UipPIzKLVii2edD+uGDjFnmAMSXCHPyclrJd+C4/KAQsO+BCAPLcRnNX9z0 TiUPVPNfz8Gw67Y4OTgU46CC77AmGx9uhADa33f3PP6GTpT1EdxNDseFML71P9TJ8Q8z7RIq6mKAp nQSN2Ua/vaHY56U21sGihqDrRSQU/sX/QfLpq6QGUlY+63zIIKXVPv0tRMSQvRrLxQZg2A3quOCI6 nSQQiJ4W5d0htyZO3fZPYcWVDBYYkyd45YHrWdV8NvbwQYDWWhk8d0Q5/U65j/tTg0KFfFIkkb6l7 c/gKa+og==; Received: from [2600:1010:b044:9528:0:4e:46fb:1201] (port=39902 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 1uP1iJ-00BY2c-1c; Tue, 10 Jun 2025 12:20:39 -0400 Date: Tue, 10 Jun 2025 09:21:56 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <8634c7fv4p.fsf@gnu.org> References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> Message-ID: <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 10, 2025 8:56:22 AM PDT, Eli Zaretskii wrote: >> Date: Tue, 10 Jun 2025 08:06:46 -0700 >> From: Daniel Colascione >> CC: pipcet@protonmail=2Ecom, 78737@debbugs=2Egnu=2Eorg >>=20 >> IOW, C-g in the command loop can mean cmderror or does it mean C-g=2E H= ow do you know? Roll the dice=2E The user cannot predict whether redisplay = is going to run at the exact moment he whacks a key=2E This particular aspe= ct of the system has been ambiguous for a long time (ever since redisplay g= ot the ability to run Lisp?) and ultimately comes from C-g being overloaded= in the first place=2E > >First, redisplay is not part of the command loop, at least not >conceptually: when redisplay runs, we don't respond to user input=2E > >And second, where we call Lisp from redisplay and cannot tolerate C-g >(or don't think it would be useful), we bind inhibit-quit already=2E > >So I don't think I follow what you are saying here=2E > >> That's *not* the same as just binding inhibit-quit around reading event= s like transient tries to do=2E The problem with binding inhibit-quit is th= at, well, you can't quit=2E Quitting restartable things that tend to get we= dged like redisplay is useful=2E > >It might be useful in principle, but if you allow that, you'll have an >infinite redisplay loop on your hands=2E Why? because quitting has the >side effect of showing "Quit" in the echo area, No, in the command loop, it would have the side effect of running whatever= C-g is bound to in the command map, and that's not necessarily (although u= sually is) going to show Quit=2E But maybe the redisplay you're interrupting has a transient problem=2E May= be you've arranged the debugger to start on quit=2E Maybe you have a runawa= y compile and you want it to stop=2E > which re-enters >redisplay right away, and will then wedge the same way as the one from >which you wanted to escape=2E And second, because it isn't restartable= =2E Sure it is=2E You can quit redisplay today and it restarts just fine=2E=20 >So aborting redisplay is tricky at best=2E We have an optional feature, >by default off, which does that, see max-redisplay-ticks=2E If you >follow how this is implemented when we decide to abort, you will see >it isn't simple=2E And my personal experience from using this is that >sometimes you are left with a partially-redrawn screen that you (as >the user) don't always know how to fix=2E If you don't want to support making redisplay interruptable, fine=2E Bind = inhibit-quit around it in every invocation by default=2E read_char still ha= s to do something with the Vquit_flag and the only sensible thing for this = function to do is translating it to quit_char and returning normally=2E >> Instead, the event reading functions should internally translate quits= =2Eto quit_char returns even if a quit happened internally=2E And they defi= nitely shouldn't return with quit-flag set=2E > >How can this support breaking out of a runaway synchronous subprocess? >Or any of the similar situations which today we can interrupt with a >C-g? are we going to give up on them? Huh? I'm talking only about translating quit to quit_char *inside read_cha= r*, not in general! If you're waiting on a synchronous subprocess, you're not in read_char ---= not unless you have such a synchronous operation in, say, a timer, and you= already can't quit one of those=2E Basically, in the command loop, once we've decided to start running a comm= and, then quits should be reflected as errors=2E If a quit happens while we= 're reading description of the command to run, control should always flow t= o the binding of quit_char in the appropriate keymaps=2E It's the only way = to keep user experience consistent=2E BTW: the problem isn't just with transient=2E It also manifests with read-= extended-command! It's a nasty race that, AFAICT, has been with us since th= e 90s=2E I think defining read_char to translate quits to quit_char solves = the problem=2E=20 From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 17:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17495762346178 (code B ref 78737); Tue, 10 Jun 2025 17:24:02 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 17:23:54 +0000 Received: from localhost ([127.0.0.1]:39419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP2hT-0001bF-48 for submit@debbugs.gnu.org; Tue, 10 Jun 2025 13:23:53 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41978) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP2hP-0001Zd-4a for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 13:23:48 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B66D210006B; Tue, 10 Jun 2025 13:23:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749576219; bh=u51iLkC0Gr9+qsDsC370p71/nkZe5kEz4Ht6EvBtKho=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=LjubHh7hOmdFa4ZMhVFCXPZG8bs4/CR3YB+O6jvaUN/22HtOKz1bpsY20jHoHD4Zu BXb0mxydH2lmIj/tm24Fl/U5Hvfx0bgtuqDlHJ+gaB3L7bOSSvTWLDahR64kja2WxG TC21HWXHqWTyvejBFU0cjcTW5po+S4HkkUq7tWVndpHzGYUNIl3T+UrKQUhP87oQjo qvB11VuKm71/ikIFDF+HNuuZoRYCFx9gPOUZK6IugqVb8SlqfPD/zOjC8fFKYJwWpw 0f2/QODNeFwYBnaUd5yGkwVz5U+vG4sK9DISiP9UVwgYVR73IcLlBHNcXralEdpP4M 31DV/2t1wtH+g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D98A7100029; Tue, 10 Jun 2025 13:23:39 -0400 (EDT) Received: from asado (unknown [86.53.241.66]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2AE2B1205FA; Tue, 10 Jun 2025 13:23:39 -0400 (EDT) From: Stefan Monnier In-Reply-To: <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> Message-ID: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> Date: Tue, 10 Jun 2025 13:23:29 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > BTW: the problem isn't just with transient. It also manifests with > read-extended-command! It's a nasty race that, AFAICT, has been with us > since the 90s. I think defining read_char to translate quits to quit_char > solves the problem. I like your way of thinking. I'm not completely sure it will solve world hunger, and it may come with regressions, but it's worth a try. Given the pervasive impact, it might be best to have a global config var to enable/disable it (with some scary internal name) until we're confident that it's an improvement. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 17:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174957725718462 (code B ref 78737); Tue, 10 Jun 2025 17:41:02 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 17:40:57 +0000 Received: from localhost ([127.0.0.1]:39463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP2xy-0004nN-Pp for submit@debbugs.gnu.org; Tue, 10 Jun 2025 13:40:56 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:10045) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP2xu-0004lM-J5 for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 13:40:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749577243; x=1749836443; bh=Ae7gP/srLhteWTZq8y5r3OaFBZaOovu7i0IbjT1cDuQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=vWoiloRSiBo4TQaoyWcBM2+k7V1f30/3uCKIdBb7dfK/ZDLLIwG9XY+2GZC5PHTH8 K9+SPfpPOYJ1Bujk4yqX22jLaR1XSXW08rEgJc0CAIJIABOz+JX5fZL7otwdEQQGLG 4rc7v5Q14P8+eaNdYFpN92qhq5JYuaq7I4/muATY36wf8mH3ShEkA2jKlPm+AVE25O SIi4bTwCPHx6Li40DPczF+vimQbXpmeglhxDELiKZ9J1WlFqpWmTGGq8IonSi15LF8 zUpw+xJgs+I8sri1ZHPCJyyFnosPugsSO1eCkvVQuMIOuwHHq1Fzf+2JXQvZ67cGCW ZFT1u+rhfefWQ== Date: Tue, 10 Jun 2025 17:40:39 +0000 From: Pip Cet Message-ID: <87msaf1omo.fsf@protonmail.com> In-Reply-To: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c6137f1385641e78435679109e6d03199734efb1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Stefan Monnier" writes: >> BTW: the problem isn't just with transient. It also manifests with >> read-extended-command! It's a nasty race that, AFAICT, has been with us >> since the 90s. I think defining read_char to translate quits to quit_cha= r >> solves the problem. > > I like your way of thinking. I'm not completely sure it will solve > world hunger, and it may come with regressions, but it's worth a try. I must be missing something: read_char translates quits to quit_char if called with inhibit-quit bound to t, and never returns with quit-flag set to t in that case. I don't think it should do that, it doesn't match the quit-flag documentation, but it is what happens right now. Do we really need a new function which is precisely equivalent to (let ((inhibit-quit t)) (read-event ...)) ? As for throw-on-input, I don't know what Daniel is proposing to do to handle it. Is every caller of read-event supposed to check throw-on-input and simulate it? How is that better than looking at quit-flag, or simply keeping inhibit-quit bound for the critical section? As for peeking at events, the easiest way seems to me to be to let-bind unread-command-events to nil around a call to read-event. That'll make it ignore them, read the next event, which you can then append to unread-command-events or not depending on whether you want the command loop to handle it. > Given the pervasive impact, it might be best to have a global config var > to enable/disable it (with some scary internal name) until we're > confident that it's an improvement. I agree it would make sense to separate inhibit-quit meaning "inhibit acting on the quit flag" and inhibit-quit meaning "inhibit setting the quit flag", but that seems a minor change. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 19:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174958410023091 (code B ref 78737); Tue, 10 Jun 2025 19:35:02 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 19:35:00 +0000 Received: from localhost ([127.0.0.1]:39991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP4kK-00060I-BA for submit@debbugs.gnu.org; Tue, 10 Jun 2025 15:35:00 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:38310) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP4kE-0005z6-Bn for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 15:34:54 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=tLwDmLSmO8KJhkn8WbIw33Tf3Od2BuzzCUNrNAgi6hM=; b=NCL0F16BN8YtHICjnPXO4A1qj+ 1SB7IMcv5QFDTtMXUBK+Ordg4zF4IKx8ahn781XOS6FDS/oZFaCcpB2IOncF79KQvc61VprX/1uNS /N1odsmxNijMp6pUJPdZHRygQaBkRy7rMSa0Ab5OyWJrxyVSdVa+w+6/EQmLeCA8m/nmhp0izWF++ YxCoGppJcHE5O27omM4PXz0WcErdDWgu0sWRShO3a0tLAb9cgo6FmIw/oMc3nqCIfQIF1mn9kH4bb ez/ovoecsEZsc9WL1JoD1bW/XVtBAJleL0nNfgrwzILmCet0oo86sAVB1G0V+cWENGUitHbaO6zCo pO7xL9hQ==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uP4ih-00BZ4y-1b; Tue, 10 Jun 2025 15:33:15 -0400 From: Daniel Colascione In-Reply-To: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Tue, 10 Jun 2025 12:34:34 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Stefan Monnier writes: >> BTW: the problem isn't just with transient. It also manifests with >> read-extended-command! It's a nasty race that, AFAICT, has been with us >> since the 90s. I think defining read_char to translate quits to quit_char >> solves the problem. > > I like your way of thinking. I'm not completely sure it will solve > world hunger, and it may come with regressions, but it's worth a try. > Given the pervasive impact, it might be best to have a global config var > to enable/disable it (with some scary internal name) until we're > confident that it's an improvement. Check out the branch dancol/quit-improvements2 with a fix for this problem and multiple others I found along the way. There, we make read_char report quits as quit_char, protect timer callbacks against quits properly, inhibit quits in redisplay by default, attempt to quit more often reading process output, and fix the original throw-on-input bug. It's now robust against the (compile "cat /dev/urandom") test, which is actually a pretty good poor man's fuzz and load test! (It's dancol/quit-improvements2 not dancol/quit-improvements because I can't force-push even to a non-mainline branch. Shouldn't we allow off-mainline force pushes?) From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 19:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet , Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174958480027578 (code B ref 78737); Tue, 10 Jun 2025 19:47:01 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 19:46:40 +0000 Received: from localhost ([127.0.0.1]:40335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP4vf-0007Ah-A6 for submit@debbugs.gnu.org; Tue, 10 Jun 2025 15:46:40 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:55970) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP4vZ-0007AP-TZ for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 15:46:37 -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=lERMmN/vSxKIug22N7q/jhykHARy5HiFp/glqxv6x74=; b=pOxciQmO5uAgiLTMk0Qs0I1jQp JMcdv5+DDyNxZaDHKU75kcqMstktLz1GPgcSXvHZNaLjh6T/xbmV/CjEALxFNY7+t+dlTvE6/4x3V hxh6qhpzBi31xF/C/XrAaGUXIjxW0vVWgmzsf6sLcZv1MHXJkBvGx82H0wNb1PeNHpX4J0yvgM0q3 vjlrpUzexOcKiV1Gbd97IHa8NqAN9+uS5d9nEkW+t5gLsmJO+gKrzXwKlLk1/cxjHhVNkSQczDrCz IphmQhFUn9IyTfjyi4/NZqiWbg3kNOZsnnx5PaWERluKUgbb4FafVIalMJ5rpLZM1DAfTTSufz9q6 lLgpiYMw==; Received: from [2600:1010:b044:9528:0:4e:46fb:1201] (port=52520 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 1uP4u3-00BZEz-0i; Tue, 10 Jun 2025 15:44:59 -0400 Date: Tue, 10 Jun 2025 12:46:19 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <87msaf1omo.fsf@protonmail.com> References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> Message-ID: <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 10, 2025 10:40:39 AM PDT, Pip Cet wrote: >"Stefan Monnier" writes: > >>> BTW: the problem isn't just with transient=2E It also manifests with >>> read-extended-command! It's a nasty race that, AFAICT, has been with u= s >>> since the 90s=2E I think defining read_char to translate quits to quit= _char >>> solves the problem=2E >> >> I like your way of thinking=2E I'm not completely sure it will solve >> world hunger, and it may come with regressions, but it's worth a try=2E > >I must be missing something: read_char translates quits to quit_char if >called with inhibit-quit bound to t, and never returns with quit-flag >set to t in that case=2E=20 You shouldn't have to call it with inhibit-quit for it do that=2E It shoul= d just happen all the time=2E I don't think it should do that, it doesn't >match the quit-flag documentation, but it is what happens right now=2E D= o >we really need a new function which is precisely equivalent to > >(let ((inhibit-quit t)) (read-event =2E=2E=2E)) ? > >As for throw-on-input, I don't know what Daniel is proposing to do to >handle it=2E Is every caller of read-event supposed to check >throw-on-input and simulate it? How is that better than looking at >quit-flag, or simply keeping inhibit-quit bound for the critical >section? See the fix in the fix i mentioned a message ago=2E Now the read event fun= ctions detect that they're in a context in which quitting is inevitable and= try to save the event before control even gets to Lisp=2E Should be transp= arent change=2E >As for peeking at events, the easiest way seems to me to be to let-bind >unread-command-events to nil around a call to read-event=2E That'll make >it ignore them, read the next event, which you can then append to >unread-command-events or not depending on whether you want the command >loop to handle it=2E Isn't unread command events kind of lossy and not something we want to use= all the time? >> Given the pervasive impact, it might be best to have a global config va= r >> to enable/disable it (with some scary internal name) until we're >> confident that it's an improvement=2E Changes seem pretty safe=2E I did add kill switch for inhibiting quit in r= edisplay=2E >I agree it would make sense to separate inhibit-quit meaning "inhibit >acting on the quit flag" and inhibit-quit meaning "inhibit setting the >quit flag", but that seems a minor change=2E We have a lot of code that makes subtle assumptions about the meaning of t= he quit flag=2E I wouldn't change it lightly=2E The more local changes on m= y branch seem sufficient=2E=20 From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 20:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174958759810807 (code B ref 78737); Tue, 10 Jun 2025 20:34:01 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 20:33:18 +0000 Received: from localhost ([127.0.0.1]:41467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP5eo-0002oF-3s for submit@debbugs.gnu.org; Tue, 10 Jun 2025 16:33:18 -0400 Received: from mout.gmx.net ([212.227.17.21]:49237) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP5em-0002nz-8D for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 16:33:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.net; s=s31663417; t=1749587588; x=1750192388; i=stephen.berman@gmx.net; bh=iyJZLQaznOkrvvDjqc+ftr34TByawKkKHIOkng1scsw=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:cc: content-transfer-encoding:content-type:date:from:message-id: mime-version:reply-to:subject:to; b=axCskwuNeGXnCzZYiyIKW/LLxcqtdkOqXCsSQezfun8al2ZLQZXufcCTr8a7+dnN Tje7ELfRDPVkvNE78vbdPTfqdAs/o2GYYQ6dFTgPhbRHsyPUd56ikgWC7osuAlx1B bcQRDZ9l0jX0LUGX+y0Agp/UeAZar+WHBG3X4Tzt33ijKFIrKPTMNh1+VCcVKo8zb PYdJVuicThphrc6uoEIXgqzPdEGPq6gaJq1gA8s86SHC/BDkDR+hvv0yRq4E6irXk HlZmfL2vRw7+lR12fOMpWGulIRd95PBCSlVlDQmWY+ZMQrODYYSBIwo+dHpdvtta5 ZI6qGmONpwKl62UVVQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from strobelfs2 ([88.130.50.123]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MV67y-1uI2Ow0Tzi-00LbFF; Tue, 10 Jun 2025 22:33:08 +0200 From: Stephen Berman In-Reply-To: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Tue, 10 Jun 2025 22:33:06 +0200 Message-ID: <87wm9jmj5p.fsf@gmx.net> MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:zJe3WSv4BMjRZRwh57sN9MJ1pNWi0Qd/8HxvzhVBKKf+z1ULJnw e5ERuffYbXlJadTZQkILOdkSd2OiBPtk2F69lzC/eqZd+WoZQ5EQ2WqWmvvg8RFP20qWV9Z KxLtJSOH/8paPbazPD5YvlEA4Zobw54iXYRI+uXTPmr8jwWf8KPLGDQuuO4pSeITsIK/yKX utkwxqmQ5L+3CSWk2QWtg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:tyLkKBub0g4=;f1HwDkaIsP0L+YwwU547AbweRbm emesMLzfRvnZaEsSfFC5qqGgX6M7U8F/7eQjvjFWG3W1jZP9RtV3xMvBomGG+MbCvtEgLJqh1 XMT6sE/52hj+iAaQxNtOfoHRGd40tw/3EEm8NFMyX+PLzkS4Y1ol6eO7XAtn+gV3AtzCmvrHR X+5107kig6zXmgz45/cmf7QdNOAioW3YLujlvs7SaHd79rltHw+1eVyLc7fKuvqf9PPr/m5VC hoTXTqc0UOPZ8q07S2MGa0ZJHg8GoR/L5eEzmUxdwm4TMX5Ru+dqvtErk1acxMlS4gvYXcnbS K83dDHKdOYAqybymnPPwobHxrgfZDkcWH3972fJbTCNQxdspY0FsECTHfJ9Dry12FY1hRkWOA cdpW6WdwTeYCip1ODPfaOPMM3gwvhyOc2t33QfVzvJdSQxzRgVq1ZiWNIzD/gyZkVk4HSGe5B /8nk3+kM9YfKEqYN6+7qiVz0l+cA9QegmNuAcxEL8evyzQR7rfIYoAakMh8YhScrlwYoIRVhK 4agC/eFrBEL6V45tsus7aAW+Gn/agOEB/5+wBrnTtjVSRcEBoi1rBWiGidGqHhtd/xZIB91B7 z+VUelJdcexx9kGLy0VOGGtitqP8pr3snNn1r7MRr9O13qhVSDnnSNyobwH+fYFt5fAqbKb37 q6AtAgJ0EwFxasitCjL4pDdqf9kKhsSKNs02eMppkN0Z7YvZAYQdKXSkBV/hiEalNHLifS7p6 cYj8RAIpmP20Vaq1tCiPZWW3xDD+LttUN9LWmCCGepjdxlNgxmh89/JktPsFh2WPHzi4DsrLn fIu1wHCtD3ZS78/TPSvzm32UYED5MUX4Nv+Iob9K0+znJP4lmbYkSjZpAhI0SI+xCm1ibstc4 IPBo1y181tGhZ4s9EfXr96dco+PrGvW1rkjWisu9KsOunelaVLerUHHVyEuv6hfnOpE+58vmn j8CDat3VZdjhobbH5PM2o+gbY8rx1qXbMJnQqd7yA9BQn3gWHWLIIfczcxGhAubnR22M6nwKS +JUJqYRTZhrhl+sUvZ2ei6WHhnFeyEuK667IedBk0QiTMEJdUegrxH4sdkuOpRqDoYI/PN+a/ JGaeDO1jr2yq7CAEpq9cwAvMsm3kxDWO4iWQ++xxcevtElgqUjChhSPcqiMXYQ5KejfuKdAN2 AFNIbIbQrYRW8RdO0MAmxUh8BTMu7rO+6VIh+5nbA32AzsGEXEZKFJYpNVJUNabDo6bEmkrF3 7HlpXjMFzcyJPFsDPjKUUqol36gs/GPd8ufG/CdcApsflslEUx3+9M0TtgmegS7eKRxg4o4Pz k+Huqy0aWSipRqFzWePKaVoRlYhH37ptmqBhAgQm6U2rsZ/wXDkn02lwJTQuLRm8QxZ70tVY9 a/HTLjgK2u1mmKe7JcGVdhkAnkkZ5HksnQcPazeUOx78EMKUhVyGYBHqqThQrLdhott7MvmtT knkzc2GYASfvcnC0U+jzhAhUebPjkUwwBRBD7AkqdEoj830FHSQMrGgejGDf6YazExj/xvg2h Lx3tZ3upk0Pku1ldzQWcp8hCDb6ZaRU98PQB+4rraZpjxwd8/3fQeXNozwDhqMKZInuv3AL1Z 3IX93aUb2v2si8qYAg8kW0HR8xGCFkUp7wSoQCkQNlt5vwbyg3RXgrDL2ApCY/tprQOzj+/pD /pjIdTbRB4PnPhDxcKvDP3KTP9rpEJ7NgvLGh4H+rZGs102Ylwn0P6vwbR+6g5w+vO4lFJ8C+ 2Fi33mR9VaU+Z8ZDp+ks+Nh+Rg4t+6+otkP87fSa/1x8BN1cVV5VyF6L69hEUkCDFXLtZv/gN tZJLABlAr5Qtcf00wvCp2FM3StOdAtRCdZYjpPWGIKrFZUPtV9ruy8odRcTnAxn/wHOmsT7ki MRiH8HYRT9Mqw5IagzVYvgN1BzcQ+1b+5FS+0udnGHyLz2eDTj+WXgOozuEnoyYnTKOy5xUGI /ZXtUEijasDUEh6r0R7djHjsT1g8d+N8uhFnUEzQ1agjtq/pIBTiNEQF6yPrlRGwik/08jGNx lmqdGWh+gO7G0m+vMzBc+FSVwgZjPREXT0+SlRL/dZ9ir0PlC9ySjqTLkIFldr0cjl62fB/zV jhg3SHRawy6RWANgESIkcS712tIn4rTNYj3YU/cn+sTgIIakqpXreg4fVLFKXtB3yA5aI9+gx uKWjFvyO/EB9Ddz5ebWkr6/2NmczDzETwmGKXSWhTPbg1o9iX4BddKopdz9/UBAQ6dzbE/qOD DWXS1mt8ZMCIcswiylq71QL8k8pP2QEnUe6EI+C5O/dkAb6R6y7ZGHDRyZckFmZ8S+jOdqve2 8Ec0+hsZZw/jSrxXD+7teA9Qqbvq2VCWFKxeD/mq3TY85EqTWLaWM00V8FFHGvvcwXCF2D3QC zF3ll/nyBR/D3Ofb61TMWktRpXcPjxmyoadUjfifZ1UUDn7NemQz3xNAKgIQDzFF8VvABmcDE D63GFiwsUb83WRDKzyP+5e8MV1Ea6K0dciUdsTQQAL2mUDxckMojxw176uriz5SRJfJUL0PaG hHJ3ShANRLNAoe6g/NZrt4LAPRCrD8uHgJZvJzYlgMznQM2Xy2PjvftjSyL8ZoNlV1LsWD3aH RZ7w5nZidJl4wMWXkzAql1RfyV3jNvjetsQyaaN8VM4Vcm796SiRDUyPad/92Hg27jE8lGnaX Jmsb+6bwLI+xddg9dCsdtELGtSDXRowqoUxKWT71be5fLV1xQ++9M+v31pbQqEHO3MhHhyrch 74hEAgfc65FXLce2Rrr8JCnNWtswZSUHdJFxr41DczczKU96JkYfCKwlFaQ7dsYSHQTc7yYUj lmXHdBUZH+6Jc4Wj2DELqqsUgEMqbh0NAHL+BrWSI6/5sj0JbcLeGMru/Tof6ZIqLl+L5wCvo sqFXRgX65TTxVii/igUMfTv/RhAFFEQYWss+73zaJg/hzTS0dKVW50P65SxR5Qo7O/ZvKc1kr 3fcTPjTX6tptJc5PGTewcYwu7s1h20adJLCV4Yyv81225S/5OPX3mpX0Zjj1A5uHoS/AniYCc yvNfpNkGnBx4e6iGiLKP8tRdHlDyx1ZmwsIpBdlHDVMLcWKNQAUU6Gke1HutpK5rHu0O+XILR qhptZH/+ntX0OH/gujeq6WbZeBCin1/LMkXG566q203loheCkhiEx9jifsubZOHeif30ix69k Q/eykYORgsNQ7VcLvWtpfa0egm7YEo5b/roJCclh2v5yRDw== Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) 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.7 (-) On Tue, 10 Jun 2025 12:34:34 -0700 Daniel Colascione w= rote: [...] > (It's dancol/quit-improvements2 not dancol/quit-improvements because I > can't force-push even to a non-mainline branch. Shouldn't we allow > off-mainline force pushes?) See admin/notes/repo in the Emacs sources: =20 * feature and scratch branches =20 Besides the master branch, which is where development takes place, and the "emacs-NN" release branches, we also have branches whose names start with "scratch/" and "feature/". The "feature/" prefix is used for feature branches that are intended to live for some time, while "scratch/" is for one-off throw-away-after-use branches. =20 We do not intend to "git merge" from scratch branches, so force-pushes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ are tolerated, as well as commits with poor style, incomplete commit ^^^^^^^^^^^^^ messages, etc. Steve Berman From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Jun 2025 20:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stephen Berman Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174958837814952 (code B ref 78737); Tue, 10 Jun 2025 20:47:02 +0000 Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 20:46:18 +0000 Received: from localhost ([127.0.0.1]:41718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uP5rN-0003t6-QW for submit@debbugs.gnu.org; Tue, 10 Jun 2025 16:46:18 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:36110) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uP5rK-0003su-CC for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 16:46:15 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=ckjjJhu5MoBxW8PNGwYGrCU6NmaXXIPrLzfbJjabaJI=; b=ncjAZqNPjLPVjEcSCt9ytIXi4v +ynWmQiOf7fU1qsyYDD3LZALbaz3lKC6wgLGHJhyTpYPEsBshc8uBtwXrtqAyifnNhfFHqz5UHxDs y8STdy8cACJaaT0u/bTAwBsxX5i+KoU8sMVh2VyWbtpnxt5+/a9XiIzsJzRJoqhnEMVpwETAL7VDY 86K36oeGsbAypHseIoSJBuSdSeQfNctRvm9ZJKobZUyNO9cay/lfu2amJZf4w+9d3ZbwVaF7Qqi7q 2aEQfSE2oyj6ylYifa8iHhADQ2UKDHGSq3bf2YNf/5mjX2uYYnI/rT0olGggcDkRQFTocUOjXD1ZD 2a3t6/jQ==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uP5pv-00BZr0-0h; Tue, 10 Jun 2025 16:44:47 -0400 From: Daniel Colascione In-Reply-To: <87wm9jmj5p.fsf@gmx.net> References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87wm9jmj5p.fsf@gmx.net> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Tue, 10 Jun 2025 13:46:06 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Stephen Berman writes: > On Tue, 10 Jun 2025 12:34:34 -0700 Daniel Colascione wrote: > > [...] >> (It's dancol/quit-improvements2 not dancol/quit-improvements because I >> can't force-push even to a non-mainline branch. Shouldn't we allow >> off-mainline force pushes?) > > See admin/notes/repo in the Emacs sources: > > * feature and scratch branches > > Besides the master branch, which is where development takes place, and > the "emacs-NN" release branches, we also have branches whose names > start with "scratch/" and "feature/". The "feature/" prefix is used > for feature branches that are intended to live for some time, while > "scratch/" is for one-off throw-away-after-use branches. > > We do not intend to "git merge" from scratch branches, so force-pushes > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > are tolerated, as well as commits with poor style, incomplete commit > ^^^^^^^^^^^^^ > messages, etc. I tried git push -f and it literally didn't work. Something about the remote not supporting fast-forward... Oh. The scratch/ is semantically meaningful! It's not just convention. I'll keep that in mind next time. Thanks! Maybe it's worth requiring that branches have one of these two prefixes? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 02:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174961062014879 (code B ref 78737); Wed, 11 Jun 2025 02:57:02 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 02:57:00 +0000 Received: from localhost ([127.0.0.1]:44046 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPBe7-0003rv-NR for submit@debbugs.gnu.org; Tue, 10 Jun 2025 22:57:00 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:41856) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPBe0-0003rV-59 for 78737@debbugs.gnu.org; Tue, 10 Jun 2025 22:56:56 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=asxLVX5DgHdcFWTJCJa0IdnfIFDxokt8+ZH4QU1XK1g=; b=PjOGKY2IxsMO482JDqpGBRbSpf bpBBzs0c9Eg2ZUh9rDZ7T2YfC+l9oa35tQ4pavbj5gId24SubWHi/s8vgWU10ghyH207zzqVpiQ3v WQ9DutUJWVvmUn6KlNrlCdfIoJEilmsXsyzDGUDAwHQick82fkQzVvl9wXSzbqgeSVIpmzEJd2VYo wh1DLj2PcFi4vJTuDjwIqYYmMnLtIeLQjC5IFfVVP3LyGd1aS6h2UU35jw2kcEc5Ghpo2RouypPCK VYAOzYhi3BiMLaGTrMzT6fZvRHdv+lMB6ED2C7llCb2V94y5kU4sG5faCXcIroH2RJbVKxDkHsga0 iDzXHSJA==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPBcf-00Bavn-20; Tue, 10 Jun 2025 22:55:29 -0400 From: Daniel Colascione In-Reply-To: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Tue, 10 Jun 2025 19:56:49 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Daniel Colascione writes: > Stefan Monnier writes: > >>> BTW: the problem isn't just with transient. It also manifests with >>> read-extended-command! It's a nasty race that, AFAICT, has been with us >>> since the 90s. I think defining read_char to translate quits to quit_char >>> solves the problem. >> >> I like your way of thinking. I'm not completely sure it will solve >> world hunger, and it may come with regressions, but it's worth a try. >> Given the pervasive impact, it might be best to have a global config var >> to enable/disable it (with some scary internal name) until we're >> confident that it's an improvement. > > Check out the branch dancol/quit-improvements2 with a fix for this > problem and multiple others I found along the way. There, we make > read_char report quits as quit_char, protect timer callbacks against > quits properly, inhibit quits in redisplay by default, attempt to quit > more often reading process output, and fix the original > throw-on-input bug. > > It's now robust against the (compile "cat /dev/urandom") test, which is > actually a pretty good poor man's fuzz and load test! > > (It's dancol/quit-improvements2 not dancol/quit-improvements because I > can't force-push even to a non-mainline branch. Shouldn't we allow > off-mainline force pushes?) BTW: I've also fixed the longstanding NS quit bug. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 10:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174963793830065 (code B ref 78737); Wed, 11 Jun 2025 10:33:02 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 10:32:18 +0000 Received: from localhost ([127.0.0.1]:47207 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPIkj-0007oq-Oz for submit@debbugs.gnu.org; Wed, 11 Jun 2025 06:32:18 -0400 Received: from mail-4322.protonmail.ch ([185.70.43.22]:64617) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPIkg-0007o9-2L for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 06:32:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749637926; x=1749897126; bh=C6bpfByUhayZxstheUuUx9yWZ3CWdz8uAam/gBvmkiA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=gcJNp6ulpL04zOLkDNalxIZGIqwhwVXUpjsosUWr59Zh4wRcMmvT2b7ykyde5d3OX a4IVJUtIj8BjTPspDmPbFZoWsw7SMPo1tZ00yAj7c6QnTe8uXzSCuT6+UGF96MEZS5 o39BIzzL6p1XACh0nSIOnBiUY0y+2Djm0SH+LX5WRj1Dskyuz2xuKsw51SBWfs1rUI 3ClTU/s70KQUi63Bqkr0JonE6NMeDjfNcXeCVhAW6jm/Vmgh9s7NCJ06JN5eG7eLcS efUxixT1/Jv5MaC/NPKdytq4GwINcvvpeyAwwKWvxDDAs+sP/vQ1i+kn29ZJ8zsbqq FOm5x5KVDRHtg== Date: Wed, 11 Jun 2025 10:32:00 +0000 From: Pip Cet Message-ID: <87h60m1sdg.fsf@protonmail.com> In-Reply-To: <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e893d16a781461ea602d6dac0643637ea3895b8b MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Daniel Colascione" writes: > On June 10, 2025 10:40:39 AM PDT, Pip Cet wrote: >>"Stefan Monnier" writes: >> >>>> BTW: the problem isn't just with transient. It also manifests with >>>> read-extended-command! It's a nasty race that, AFAICT, has been with u= s >>>> since the 90s. I think defining read_char to translate quits to quit_c= har >>>> solves the problem. >>> >>> I like your way of thinking. I'm not completely sure it will solve >>> world hunger, and it may come with regressions, but it's worth a try. >> >>I must be missing something: read_char translates quits to quit_char if >>called with inhibit-quit bound to t, and never returns with quit-flag >>set to t in that case. > > You shouldn't have to call it with inhibit-quit for it do that. It should= just happen all the time. But we don't usually want read-event to eat quits and report them by returning quit_char. The old behavior gave me a choice. (while t (read-event)) on your branch appears to hang the Emacs session unquittably (even SIGUSR2 doesn't seem to work). It should permit quits, because that code says nothing about wanting quits to be reported. Reporting them as quit_char doesn't always make sense, since there are other ways to generate a quit, such as SIGUSR2, and quit_char can change. > I don't think it should do that, it doesn't >>match the quit-flag documentation, but it is what happens right now. Do >>we really need a new function which is precisely equivalent to >> >>(let ((inhibit-quit t)) (read-event ...)) ? >> >>As for throw-on-input, I don't know what Daniel is proposing to do to >>handle it. Is every caller of read-event supposed to check >>throw-on-input and simulate it? How is that better than looking at >>quit-flag, or simply keeping inhibit-quit bound for the critical >>section? > > See the fix in the fix i mentioned a message ago. Now the read event > functions detect that they're in a context in which quitting is > inevitable and try to save the event before control even gets to > Lisp. Should be transparent change. It's pushing the event without the (cons t event) wrapper now? Won't that change behavior of sit-for (and adding the wrapper would change behavior of other users)? Maybe we should just fix the original problem by making read_char call maybe_quit instead of removing an event from the queue, if Vquit_flag is set. No reason to change anything about the API, read_char already calls Lisp so quitting should not be a problem (famous last words). Of course, the ability to peek at/wait for events would still be a good thing, as would the ability to nest while-no-input invocations. >>As for peeking at events, the easiest way seems to me to be to let-bind >>unread-command-events to nil around a call to read-event. That'll make >>it ignore them, read the next event, which you can then append to >>unread-command-events or not depending on whether you want the command >>loop to handle it. > > Isn't unread command events kind of lossy and not something we want to us= e all the time? How is it "kind of lossy"? Anyway, you're using it on your branch, so if it's unsafe it'll be unsafe for you, too. If your concern is that unread-command-events might be updated asynchronously as quit-flag is, I don't think we do that. >>I agree it would make sense to separate inhibit-quit meaning "inhibit >>acting on the quit flag" and inhibit-quit meaning "inhibit setting the >>quit flag", but that seems a minor change. > > We have a lot of code that makes subtle assumptions about the meaning > of the quit flag. I wouldn't change it lightly. The more local changes > on my branch seem sufficient. Er, you just did change it, in a way that breaks existing behavior. But I agree, no changes such as that one are necessary. Anyway, here are the minor changes to keyboard.c to avoid the original problem (the third change is somewhat independent and avoids quitting in kbd_buffer_get_event): diff --git a/src/keyboard.c b/src/keyboard.c index 5db11ad6379..5c65111f649 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -3045,6 +3045,9 @@ read_char (int commandflag, Lisp_Object map, timer_stop_idle (); RESUME_POLLING; =20 + input_was_pending =3D input_pending; + maybe_quit (); + if (NILP (c)) { if (commandflag >=3D 0 @@ -4118,6 +4121,11 @@ kbd_buffer_get_event (KBOARD **kbp, x_handle_pending_selection_requests (); #endif =20 + /* We're about to dequeue an event; if quit-flag is set, we might + never get around to handling it, so it would be lost. */ + if (!NILP (Vquit_flag)) + quit_throw_to_read_char (0); + if (CONSP (Vunread_command_events)) { Lisp_Object first; @@ -12992,7 +13000,7 @@ is_ignored_event (union buffered_input_event *event= ) default: ignore_event =3D Qnil; break; } =20 - return !NILP (Fmemq (ignore_event, Vwhile_no_input_ignore_events)); + return !NILP (memq_no_quit (ignore_event, Vwhile_no_input_ignore_events)= ); } =20 static void syms_of_keyboard_for_pdumper (void); Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 12:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174964564716339 (code B ref 78737); Wed, 11 Jun 2025 12:41:02 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 12:40:47 +0000 Received: from localhost ([127.0.0.1]:48069 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPKl4-0004FQ-Oe for submit@debbugs.gnu.org; Wed, 11 Jun 2025 08:40:47 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:42972) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPKl1-0004F1-0J for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 08:40:44 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=rJDC1B93HDBXtiYKp2K7XiC33SFPpUdnx3SFAUzBPKU=; b=kXOntx5Ykw9hHw05YChN/p5bZW alp0jo2ztGrQP/EsHGlItqMWCOEoXuMNH0r0eBwdnLuFItm9Ac1K+xXd0EmGjGIjTpAatEgwKgyjD +F83cQINuxf9a+0YceQ+OI5P5wzvUdK5cIogSxxgNR2/1gDLRJYdZKMyVKyx1sVX8/nDITrRJc312 g1/fTsX4qJbiEMBPmMWps8YGsQE+DRIclMglsejeFdKbjo72A0JAslKVEnOptbS+Zgi/wAmhxOj/c fEgeWZlPLwCZyZqJwVGd9Qsa8zwOKlEdwIVSjrfK3Sz1Uy5AIYV59JeyWKnA1R5TLZJoS4HzNqo6e euVRF7Wg==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPKjV-00BdVF-0o; Wed, 11 Jun 2025 08:39:09 -0400 From: Daniel Colascione In-Reply-To: <87h60m1sdg.fsf@protonmail.com> References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Wed, 11 Jun 2025 05:40:29 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Pip Cet writes: > "Daniel Colascione" writes: > >> On June 10, 2025 10:40:39 AM PDT, Pip Cet wrote: >>>"Stefan Monnier" writes: >>> >>>>> BTW: the problem isn't just with transient. It also manifests with >>>>> read-extended-command! It's a nasty race that, AFAICT, has been with us >>>>> since the 90s. I think defining read_char to translate quits to quit_char >>>>> solves the problem. >>>> >>>> I like your way of thinking. I'm not completely sure it will solve >>>> world hunger, and it may come with regressions, but it's worth a try. >>> >>>I must be missing something: read_char translates quits to quit_char if >>>called with inhibit-quit bound to t, and never returns with quit-flag >>>set to t in that case. >> >> You shouldn't have to call it with inhibit-quit for it do that. It should just happen all the time. > > But we don't usually want read-event to eat quits and report them by > returning quit_char. The old behavior gave me a choice. You still have a choice. You can signal quit if you get a quit event. > (while t (read-event)) > > on your branch appears to hang the Emacs session unquittably (even > SIGUSR2 doesn't seem to work). It should permit quits, because that > code says nothing about wanting quits to be reported. By calling read-event, you're asking Emacs read an event. C-g is an event. Lisp isn't saying read-event-unless-it's-C-g-in-which-case-exit-non-locally. Lisp says read-event. Emacs is doing exactly what Lisp is asking it to do. If Lisp wants to quit in response to a char_char event, it can just (signal 'quit nil). Besides, (let ((inhibit-quit t)) (while t (read-event))) will be similarly unquittable on master today. (while t ((read-key-sequence "))) is unquittable too. On current master, (read-event) then C-g signals quit but (read-key-sequence "") C-g returns a quit_char key. Why? Why should we expect (while t (read-event)) to be quittable but not (while t (read-key-sequence "")), which can't be quit today on master? Why would the _high level_ event reading function report quit as a character but the low-level one exit nonlocally? Consider, say, (let ((unread-command-events '(\?C-g))) (read-event)). That'll return \?C-g, not quit. Therefore, anyone who calls (read-event) has to account for both ways of C-g being reported. What's the benefit of this complexity? So what if the behavior of read-event changes? Does having read-event report a quit as an event actually break anything considering that _sometimes_ it already can report a C-g as an event and not a quit signal. We need to be consistent about how we treat C-g when reading events. It makes no sense to quit while reading an event because in order to quit, you must first read an event! The current ambiguity is confusing and leads to real-world actual bugs. A lisp-visible behavior change isn't dispositive by itself: any resolution of the current ambiguity will result in new behavior, so we might as well make it good new behavior. If C-g means quit, we should resolve the inconsistency above by having read-event quit if it finds a C-g events in a queue. We also need to change cmd_error to detect quits, push a synthetic quit_char to unread_command_events, return Qt, and have the command loop look up the event on the next loop. That'll fix the transient bug. If C-g means quit_char, which is the better behavior, we need to document that functions that read events report quits as quit_char. Thanks for pointing out the SIGUSR2 thing. That's just a bug we'll fix on the branch. Likewise, we should try to get the emergency quit mechanism working somehow too. None of this means that (read-event) then physically hitting C-g means (read-event) should quit rather than return. > Reporting them as quit_char doesn't always make sense, since there are > other ways to generate a quit, such as SIGUSR2, We can make SIGUSR2 generate a subtype of quit and have read_char translate only the basic event. Likewise for emergency quits. > and quit_char can change. Can it in practice? Lots of stuff hardcodes C-g and I'm not confident that a non-default quit_char would produce usable behavior. I'd rather just remove set-quit-char than worry about quit_char changing. >> I don't think it should do that, it doesn't >>>match the quit-flag documentation, but it is what happens right now. Do >>>we really need a new function which is precisely equivalent to >>> >>>(let ((inhibit-quit t)) (read-event ...)) ? >>> >>>As for throw-on-input, I don't know what Daniel is proposing to do to >>>handle it. Is every caller of read-event supposed to check >>>throw-on-input and simulate it? How is that better than looking at >>>quit-flag, or simply keeping inhibit-quit bound for the critical >>>section? >> >> See the fix in the fix i mentioned a message ago. Now the read event >> functions detect that they're in a context in which quitting is >> inevitable and try to save the event before control even gets to >> Lisp. Should be transparent change. > > It's pushing the event without the (cons t event) wrapper now? Won't > that change behavior of sit-for (and adding the wrapper would change > behavior of other users)? > > Maybe we should just fix the original problem by making read_char call > maybe_quit instead of removing an event from the queue, if Vquit_flag is > set. I don't think it's a good idea to have parallel event processing paths, one for events delivered as Lisp objects and one for events delivered as signals. > No reason to change anything about the API, read_char already calls Lisp > so quitting should not be a problem (famous last words). > > Of course, the ability to peek at/wait for events would still be a good > thing, as would the ability to nest while-no-input invocations. > >>>As for peeking at events, the easiest way seems to me to be to let-bind >>>unread-command-events to nil around a call to read-event. That'll make >>>it ignore them, read the next event, which you can then append to >>>unread-command-events or not depending on whether you want the command >>>loop to handle it. >> >> Isn't unread command events kind of lossy and not something we want to use all the time? > > How is it "kind of lossy"? Anyway, you're using it on your branch, so > if it's unsafe it'll be unsafe for you, too. > > If your concern is that unread-command-events might be updated > asynchronously as quit-flag is, I don't think we do that. > >>>I agree it would make sense to separate inhibit-quit meaning "inhibit >>>acting on the quit flag" and inhibit-quit meaning "inhibit setting the >>>quit flag", but that seems a minor change. >> >> We have a lot of code that makes subtle assumptions about the meaning >> of the quit flag. I wouldn't change it lightly. The more local changes >> on my branch seem sufficient. > > Er, you just did change it, in a way that breaks existing behavior. But > I agree, no changes such as that one are necessary. The above is talking about changing the low-level meaning of Vinhibit_quit in C. Lots of code assumes that binding Vinhibit_quit will result in Vquit_flag being set and I'm a lot more worried about breaking things as a result of changing _that_ behavior than I am about making read_char consistent about how it reports C-g. > Anyway, here are the minor changes to keyboard.c to avoid the original > problem (the third change is somewhat independent and avoids quitting in > kbd_buffer_get_event): This change papers over the problem of ambiguous C-g representation without trying to fix it or address the even worse problem of the quits going to the event loop and not being looked up as commands. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 13:25:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: dancol@dancol.org, Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174964826131334 (code B ref 78737); Wed, 11 Jun 2025 13:25:06 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 13:24:21 +0000 Received: from localhost ([127.0.0.1]:48383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPLRF-00089J-0F for submit@debbugs.gnu.org; Wed, 11 Jun 2025 09:24:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57104) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPLRA-00088s-UO for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 09:24:18 -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 1uPLR3-0007m6-CV; Wed, 11 Jun 2025 09:24:09 -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=kSqecHjdexukcDjK5V7GUEiu1FvWjmkPzteX76A5HjQ=; b=NKv+6m0QFR1I pk67wres+YO44Ia03rwsw9E/hy47V0fpdSrOXMo/WU2SerrcowNhcKZiX9po1ZRW8t1rqrIXRSnPe whGNcv8gwFu9UMt4WdsKNH/JPSzRJ5HE/PYW24DK8f1rN2CIXd2OhUOcx3ROcvf649/IkioTFDyl7 AVpIXVrGqmd05DJQRpWh5CQMlLWl5oQS6kayop67hAHibfxTJqafzcHVGfjH3F0Fh+yKgZyyhHXfm 2j4wRlOpaF3TKMNrg4W2PCtgELsAj7EJyeg3FkoTeYkHPIagaXGItyh/m53GOeR2+a5TrZp6xko8d htEQey5nx1IeYS0RfJ098Q==; Date: Wed, 11 Jun 2025 16:23:40 +0300 Message-Id: <86jz5ie7j7.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Tue, 10 Jun 2025 13:23:29 -0400) References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , pipcet@protonmail.com, > 78737@debbugs.gnu.org > Date: Tue, 10 Jun 2025 13:23:29 -0400 > > > BTW: the problem isn't just with transient. It also manifests with > > read-extended-command! It's a nasty race that, AFAICT, has been with us > > since the 90s. I think defining read_char to translate quits to quit_char > > solves the problem. > > I like your way of thinking. I'm not completely sure it will solve > world hunger, and it may come with regressions, but it's worth a try. > Given the pervasive impact, it might be best to have a global config var > to enable/disable it (with some scary internal name) until we're > confident that it's an improvement. This code is used everywhere, and we have no one on board who knows it (and its many quirks and platform-dependent subtleties) well enough. It isn't an accident that we prefer not to make changes in it: each time we made even small changes in this code we ended up with regressions. We don't have any decent test suite for the this part of Emacs. We don't even have an exhaustive list of features/commands/operations to test in order to make sure some change doesn't break them. Notable corners that get frequently broken by changes in this area: keyboard macros, Leim input methods, and non-keyboard input events. So yes, we definitely need such a knob, if we are seriously considering to merge these changes. Daniel, would you please add such a knob? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 13:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17496491213756 (code B ref 78737); Wed, 11 Jun 2025 13:39:02 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 13:38:41 +0000 Received: from localhost ([127.0.0.1]:48502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPLf7-0000yT-0j for submit@debbugs.gnu.org; Wed, 11 Jun 2025 09:38:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52426) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPLf3-0000xv-Ch for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 09:38:38 -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 1uPLex-0000qy-1l; Wed, 11 Jun 2025 09:38:31 -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=lsfw4vtvgTxP1Q6DRnxBZd8gsSKgrXFE6GgFr3N1/Sg=; b=S9uwRiqMfp4Z evm6Vi1CMm88fCBHTH1gGkwmbQhnDWkIZ/TTpMfuESfYLbq2ui1hzC5+N5h5IqDwjUQjhfPwGUgh5 VtDJR99qe+jLj2Vweh3jWDECsCYMC33v0Zs6wY83eqwlAy6JPkDPSSm3v8sVWra6DEZdwWOQnOQV5 0uZVCV1qNdr5Xzb6LGS2MX6gDQEIZ77dJPQpHGrufmOaMIBYR4j10nOhYeS1wgltFUE5ftsUB7H1+ +7D3IBAA0BVVqo8+ogeqF7Q/nQ9gKSx1w9X1dhUdFjZAmdLbsd++Z7xJZhB1gAbMLedujnpmyy/nR BQ9BK8f84dJ5W75gfaM67g==; Date: Wed, 11 Jun 2025 16:38:28 +0300 Message-Id: <86frg6e6uj.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Wed, 11 Jun 2025 05:40:29 -0700) References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> X-Spam-Score: -2.3 (--) 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 (---) > From: Daniel Colascione > Cc: Stefan Monnier , Eli Zaretskii > , 78737@debbugs.gnu.org > Date: Wed, 11 Jun 2025 05:40:29 -0700 > > Pip Cet writes: > > > (while t (read-event)) > > > > on your branch appears to hang the Emacs session unquittably (even > > SIGUSR2 doesn't seem to work). It should permit quits, because that > > code says nothing about wanting quits to be reported. > > By calling read-event, you're asking Emacs read an event. C-g is an > event. Lisp isn't saying > read-event-unless-it's-C-g-in-which-case-exit-non-locally. Lisp says > read-event. Emacs is doing exactly what Lisp is asking it to do. How is calling read-event different from calling any other primitive in this context? Typing C-g while any Lisp primitive is called is expected to throw to top-level, instead of doing whatever the primitive's contract says. Why is read-event different in this regard? > Besides, (let ((inhibit-quit t)) (while t (read-event))) will be > similarly unquittable on master today. Because the caller explicitly didn't want it to be quittable. > On current master, (read-event) then C-g signals quit but > (read-key-sequence "") C-g returns a quit_char key. Why? Why should we > expect (while t (read-event)) to be quittable but not (while t > (read-key-sequence "")), which can't be quit today on master? Why would > the _high level_ event reading function report quit as a character but > the low-level one exit nonlocally? Because a higher-level function knows the context better? I don't see anything wrong with that. > So what if the behavior of read-event changes? Does having read-event > report a quit as an event actually break anything considering that > _sometimes_ it already can report a C-g as an event and not a > quit signal. Sorry, we cannot assume that attitude, not in this case. Making incompatible behavior changes in this area means we will definitely break enough use cases to cause a flood of bug reports. We cannot do that so freely and nonchalantly. We could perhaps make it an optional behavior, but that's all. I appreciate the urge to fix what you perceive as inconsistencies, but that alone doesn't IMO justify risky incompatible changes in default behavior, especially if they leave no "fire escape". Please understand where I stand on this. This position isn't arbitrary, it is based on our experience from making changes in this area in the recent years. > The current ambiguity is confusing and leads to real-world actual bugs. > A lisp-visible behavior change isn't dispositive by itself: any > resolution of the current ambiguity will result in new behavior, so we > might as well make it good new behavior. We could also leave the old behavior alone. It isn't bad behavior. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 14:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174965094725839 (code B ref 78737); Wed, 11 Jun 2025 14:10:01 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 14:09:07 +0000 Received: from localhost ([127.0.0.1]:49632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPM8U-0006hr-E4 for submit@debbugs.gnu.org; Wed, 11 Jun 2025 10:09:06 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:42580) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPM8O-0006gR-Uj for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 10:08:59 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=kDFk3BRnslMcOylT0kb5W3NokZEP38SkB5bPQY8DgD8=; b=ANQadhfvQ8FEzy+Qsht4mJc4Ol ooYiJOQLCbKE05B60Y+3wb05ItCI6agBq7+bAll+R6wxCuHrD/n0+AyR44+i1dmwsxP6CNxr7LmKs xtXaeJpxtlcD0ke49S6fQwT6m6dVFwS78hmsX78cfBMFr+R0U3Wg0LuTZcNRRXXu0Beh+XiQVOhkJ 3nIrsKOJmDJwe37pldNy+hcwMFZm4vSnlZwiaaA0acnFExNTisHAzhuBis/bSWDjN8i76KpcdlUUF CHcZc5BXMVQRhqtDVEghuj95vMyfHESDV+N3BvDC9ZG1sqv5jDC/AqOGDBARMCgdt4O/miCztHysX Q0e4NpBg==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPM6v-00BeqH-24; Wed, 11 Jun 2025 10:07:25 -0400 From: Daniel Colascione In-Reply-To: <86frg6e6uj.fsf@gnu.org> References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Wed, 11 Jun 2025 07:08:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Eli Zaretskii writes: >> From: Daniel Colascione >> Cc: Stefan Monnier , Eli Zaretskii >> , 78737@debbugs.gnu.org >> Date: Wed, 11 Jun 2025 05:40:29 -0700 >> >> Pip Cet writes: >> >> > (while t (read-event)) >> > >> > on your branch appears to hang the Emacs session unquittably (even >> > SIGUSR2 doesn't seem to work). It should permit quits, because that >> > code says nothing about wanting quits to be reported. >> >> By calling read-event, you're asking Emacs read an event. C-g is an >> event. Lisp isn't saying >> read-event-unless-it's-C-g-in-which-case-exit-non-locally. Lisp says >> read-event. Emacs is doing exactly what Lisp is asking it to do. > > How is calling read-event different from calling any other primitive > in this context? Typing C-g while any Lisp primitive is called is > expected to throw to top-level, instead of doing whatever the > primitive's contract says. Why is read-event different in this > regard? Why is it good that read-key-sequence swallows quits but not read-char? C-g is an event. Why should read-event (but not read-key-sequence?) translate one kind of input event (C-g) to an action (signal quit) but return other kinds of events as they're given? >> Besides, (let ((inhibit-quit t)) (while t (read-event))) will be >> similarly unquittable on master today. > > Because the caller explicitly didn't want it to be quittable. The caller asked to read an event. That's exactly what we did. The way to reduce the likelihood of bugs is not to freeze the code, but to understand it, simplify its contract, and probably write some tests and documentation. What specifically do you think might break here? >> On current master, (read-event) then C-g signals quit but >> (read-key-sequence "") C-g returns a quit_char key. Why? Why should we >> expect (while t (read-event)) to be quittable but not (while t >> (read-key-sequence "")), which can't be quit today on master? Why would >> the _high level_ event reading function report quit as a character but >> the low-level one exit nonlocally? > > Because a higher-level function knows the context better? I don't see > anything wrong with that. The higher level function wants to read an event. That's exactly what this function does now. >> So what if the behavior of read-event changes? Does having read-event >> report a quit as an event actually break anything considering that >> _sometimes_ it already can report a C-g as an event and not a >> quit signal. > > Sorry, we cannot assume that attitude, not in this case. Making > incompatible behavior changes in this area means we will definitely > break enough use cases to cause a flood of bug reports. We cannot do > that so freely and nonchalantly. We could perhaps make it an optional > behavior, but that's all. > > I appreciate the urge to fix what you perceive as inconsistencies, but > that alone doesn't IMO justify risky incompatible changes in default > behavior, especially if they leave no "fire escape". Please > understand where I stand on this. This position isn't arbitrary, it > is based on our experience from making changes in this area in the > recent years. We can't just avoid changing things because we don't understand the code. I put a fair bit of time into understanding this code, and that means >> The current ambiguity is confusing and leads to real-world actual bugs. >> A lisp-visible behavior change isn't dispositive by itself: any >> resolution of the current ambiguity will result in new behavior, so we >> might as well make it good new behavior. > > We could also leave the old behavior alone. It isn't bad behavior. So you're saying it's a good thing that the behavior of the code changes depending on whether it's compiled? You're right: that's not bad behavior. It's abysmal behavior. This whole area is full of bugs. Are we seriously in "fixing bugs is bad because something might change" territory? In a development branch? With a knob (for now) to revert to the old, broken behavior? One way to make the code more understandable is to make it consistent and clearly define its contract. When code has a regular structure, you don't need to keep a thousand special cases in your mind when working on it. Regularity allows you to substitute reason for memory. The code is pretty irregular right now. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 14:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174965180730127 (code B ref 78737); Wed, 11 Jun 2025 14:24:02 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 14:23:27 +0000 Received: from localhost ([127.0.0.1]:49732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPMMO-0007pJ-K8 for submit@debbugs.gnu.org; Wed, 11 Jun 2025 10:23:26 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:31475) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPMMK-0007ni-6N for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 10:23:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749651793; x=1749910993; bh=7EB+gxiRHUzYTvP4xw3mQb3srCbcoumc7NOiXL/stbQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=WU9r8O/HDp32GCe9RnhlaK5syFkSL3I7UWdXdgsHNDBBnLrmn+ATuYoMaYl2kWj7O pB0rCHTEkLzuHJ1kycMTg1EmKsdLM+YOmzKNlKyeREyTlSFcuJYulsM2OIFok9Sqca PELmiQL4DPD0pb3CXLf1UI+yHgYHbY4v/SVEUlYHRgTFQStP/0lINa99l8g+/jSbsf qd7Imq3YOcyKEUBgIhpaV+sd6q3KfOgNm9fZhAHigqtNzm30lnDXqfvGnz3E2onrFU NaRFT7lq+2vwL08em0WPMdaoPFboVB9EjWILEnOBE6i6X84nwANStimbM6U6ZUDDjf cIV7Iucd8ZtTw== Date: Wed, 11 Jun 2025 14:23:07 +0000 From: Pip Cet Message-ID: <87bjqu1ho9.fsf@protonmail.com> In-Reply-To: References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c47c4c3fc1f515fc8fb112f5c5bb451c697be817 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Daniel Colascione" writes: > Pip Cet writes: > >> "Daniel Colascione" writes: >> >>> On June 10, 2025 10:40:39 AM PDT, Pip Cet wrote= : >>>>"Stefan Monnier" writes: >>>> >>>>>> BTW: the problem isn't just with transient. It also manifests with >>>>>> read-extended-command! It's a nasty race that, AFAICT, has been with= us >>>>>> since the 90s. I think defining read_char to translate quits to quit= _char >>>>>> solves the problem. >>>>> >>>>> I like your way of thinking. I'm not completely sure it will solve >>>>> world hunger, and it may come with regressions, but it's worth a try. >>>> >>>>I must be missing something: read_char translates quits to quit_char if >>>>called with inhibit-quit bound to t, and never returns with quit-flag >>>>set to t in that case. >>> >>> You shouldn't have to call it with inhibit-quit for it do that. It shou= ld just happen all the time. >> >> But we don't usually want read-event to eat quits and report them by >> returning quit_char. The old behavior gave me a choice. > > You still have a choice. You can signal quit if you get a quit event. Making (while t (read-event)) infloop without being able to quit is a bad idea. We shouldn't do it. >> (while t (read-event)) >> >> on your branch appears to hang the Emacs session unquittably (even >> SIGUSR2 doesn't seem to work). It should permit quits, because that >> code says nothing about wanting quits to be reported. > > By calling read-event, you're asking Emacs read an event. C-g is an > event. It's not an ordinary event. It's an event that should be handled specially, which is what we do now and should continue doing. There's a way around that, but the vast majority of callers don't need to worry about it: (read-event) should read an ordinary event and return it, without breaking quit. > Lisp isn't saying > read-event-unless-it's-C-g-in-which-case-exit-non-locally. Lisp says > read-event. That's implicit as for any other Lisp command that isn't specifically documented not to quit. (As, for example, read-key-sequence is). >> Anyway, here are the minor changes to keyboard.c to avoid the original >> problem (the third change is somewhat independent and avoids quitting in >> kbd_buffer_get_event): > > This change papers over the problem of ambiguous C-g representation It doesn't paper over anything. It merely quits before dequeueing events when throw-on-input is in effect, without any major changes. > without trying to fix it or address the even worse problem of the quits > going to the event loop and not being looked up as commands. Are you saying quits should *generally* be treated as commands rather than by the event loop? Because my opinion is precisely the opposite: quits should always be handled by C code, never by keyboard-quit, because that's what they are used for: to break out of misbehaving Lisp code, with minimal involvement of Lisp machinery which may be misbehaving. We'd need new, incompatible versions of almost all callers, because those do want to quit when we hit C-g. And, again, we're taking away the choice "act on C-g as usual", replacing it by a new "identify (somehow) quit events and (somehow) quit when you see one". Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 14:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174965220332131 (code B ref 78737); Wed, 11 Jun 2025 14:31:01 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 14:30:03 +0000 Received: from localhost ([127.0.0.1]:49797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPMSo-0008Lp-2Z for submit@debbugs.gnu.org; Wed, 11 Jun 2025 10:30:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35826) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPMSk-0008Ku-HP for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 10:29:59 -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 1uPMSd-0006k2-D4; Wed, 11 Jun 2025 10:29:51 -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=jb8oHMli5x7Tk/LoQKESUCd8iu+uCvhVr1hAKhJaVnw=; b=lFIxK7h8WRB7 I84Wkm/SQPOYgxGgJiNH9XZp6I81Gr6ag1gWna7jf5e5a9B07c7hQZcskDfry7ANbjQjp3IFpQmW7 a4gw8GPNu4jyWscANQZlqwXarKfXgYl8gtzH1iK5X09oCP+cyHFCyhLyEFmWDdCkGFcGKcF8OgPB0 5yETlhnMaKDHxP40Aa4VMX9ESlP4pG3xrw96xRSIOBhro/BsOCGKhuB49S+Nwc30WTvSMWJVCo1Aj M71QKfYMX3+QyzBBPvYaytrvW8/IpD6nu79UkfZrOCVgbXLedEA9DZihwY1U3H2KNcQid6MVV588L r3z1STJKf9O13kBM3hYebA==; Date: Wed, 11 Jun 2025 17:29:48 +0300 Message-Id: <86v7p2gxlv.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Wed, 11 Jun 2025 07:08:45 -0700) References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Daniel Colascione > Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > Date: Wed, 11 Jun 2025 07:08:45 -0700 > > Why is it good that read-key-sequence swallows quits but not read-char? I don't know. No one does. maybe there's a good reason for it, maybe there was one at some point but there isn't anymore, maybe it's just a historical accident. But being unable to answer such questions doesn't mean changing the behavior is safe. It usually is the other way around, in a program as old and complex as |Emacs. > C-g is an event. Why should read-event (but not read-key-sequence?) > translate one kind of input event (C-g) to an action (signal quit) but > return other kinds of events as they're given? You consider this to be an inconsistency based only on the name of the API. But that's not necessarily the whole contract of the API. It doesn't need to be called get-char-quit-when-c-g to behave like it does. Anyway, I think arguing about this aspect is not useful. My problem is not theoretical, it is practical: how much will break due to these changes, and how long will it take us to become aware of the breakage and attempt fixing it? > What specifically do you think might break here? Not in those toy examples, but in much larger programs where these are used. And I know what will break. As I told, we don't have a good set of tests for it. I only know that every time we changed something in read_char and its ilk in recent years, we ended up with regressions. > The higher level function wants to read an event. That's exactly what > this function does now. How do we know that is all that's expected from it? just because its name says so? > > Sorry, we cannot assume that attitude, not in this case. Making > > incompatible behavior changes in this area means we will definitely > > break enough use cases to cause a flood of bug reports. We cannot do > > that so freely and nonchalantly. We could perhaps make it an optional > > behavior, but that's all. > > > > I appreciate the urge to fix what you perceive as inconsistencies, but > > that alone doesn't IMO justify risky incompatible changes in default > > behavior, especially if they leave no "fire escape". Please > > understand where I stand on this. This position isn't arbitrary, it > > is based on our experience from making changes in this area in the > > recent years. > > We can't just avoid changing things because we don't understand the > code. I put a fair bit of time into understanding this code, and that > means I didn't say we cannot make changes there. I said we should be very cautious if and when we do. Which means: . we should think hard and then think again whether the change is really necessary and how important are the problems that it solves or new features it allows . we should have a knob to revert to previous behavior > > We could also leave the old behavior alone. It isn't bad behavior. > > > So you're saying it's a good thing that the behavior of the code changes > depending on whether it's compiled? No, I'm saying that in this case it could be minor enough and rare enough to fail to outweigh the risks. > This whole area is full of bugs. Are we seriously in "fixing bugs is > bad because something might change" territory? In a development branch? > With a knob (for now) to revert to the old, broken behavior? See above: that's not what I'm saying. > One way to make the code more understandable is to > make it consistent and clearly define its contract. When code has a > regular structure, you don't need to keep a thousand special cases in > your mind when working on it. Regularity allows you to substitute > reason for memory. The code is pretty irregular right now. I agree, but when dealing with old and very complex code that thousands of programs rely upon, we need to consider the risks of changing the old behavior even if it is somewhat inconsistent. Because sometimes an old, known, and minor problem is better than new, unknown, and exciting ones. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 14:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17496533746266 (code B ref 78737); Wed, 11 Jun 2025 14:50:02 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 14:49:34 +0000 Received: from localhost ([127.0.0.1]:49967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPMlh-0001cv-Hs for submit@debbugs.gnu.org; Wed, 11 Jun 2025 10:49:34 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:56842) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPMle-0001cj-Od for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 10:49:31 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=HBnmv3OWpjEnK/L5F3fzO86oat4MMmMV0XLpDzzNEdk=; b=PZwttCE+daABVcHGkNTAc/Ovla Ko0kmmIZFGB7o3Kqvs3Em3v5yvaU0ZwyqG5o75rb+4A0RDJBH6d5x9rU9ZGibmso+7cfkDNil+wBk djAz2aBCl0rOaX26ausXUqxJbLO+nt9E/AWgQWktuLcRLU3UX2E3/M3j2sQYfnlif/n7ZH/vyoMsp cmVl9ODLisvdWddPwNT1I7gILRBDXgIFsN7PV4Ss8G3BCFp/KXI57rqfOteqonndenqthw8PSe9g5 eDJdCqfOQS+iq5XZ9WGhNBzm44pAqQDJD8ukVOmGuvX3iQiB8AQm17KLb90gK8HOr3LwWsIZqbRiu T8hSw57Q==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPMkF-00Bft6-1w; Wed, 11 Jun 2025 10:48:03 -0400 From: Daniel Colascione In-Reply-To: <87bjqu1ho9.fsf@protonmail.com> References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Wed, 11 Jun 2025 07:49:23 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Pip Cet writes: > "Daniel Colascione" writes: > >> Pip Cet writes: >> >>> "Daniel Colascione" writes: >>> >>>> On June 10, 2025 10:40:39 AM PDT, Pip Cet wrote: >>>>>"Stefan Monnier" writes: >>>>> >>>>>>> BTW: the problem isn't just with transient. It also manifests with >>>>>>> read-extended-command! It's a nasty race that, AFAICT, has been with us >>>>>>> since the 90s. I think defining read_char to translate quits to quit_char >>>>>>> solves the problem. >>>>>> >>>>>> I like your way of thinking. I'm not completely sure it will solve >>>>>> world hunger, and it may come with regressions, but it's worth a try. >>>>> >>>>>I must be missing something: read_char translates quits to quit_char if >>>>>called with inhibit-quit bound to t, and never returns with quit-flag >>>>>set to t in that case. >>>> >>>> You shouldn't have to call it with inhibit-quit for it do that. It should just happen all the time. >>> >>> But we don't usually want read-event to eat quits and report them by >>> returning quit_char. The old behavior gave me a choice. >> >> You still have a choice. You can signal quit if you get a quit event. > > Making > > (while t (read-event)) > > infloop without being able to quit is a bad idea. We shouldn't do it. So we should "fix" read-key-sequence so that it, too, quits? >>> (while t (read-event)) >>> >>> on your branch appears to hang the Emacs session unquittably (even >>> SIGUSR2 doesn't seem to work). It should permit quits, because that >>> code says nothing about wanting quits to be reported. >> >> By calling read-event, you're asking Emacs read an event. C-g is an >> event. > > It's not an ordinary event. The problem is that C-g is ordinary event on some code paths and not others. > It's an event that should be handled > specially, which is what we do now and should continue doing. So if I stuff C-g into unread-command-events and then call (read-event), I should get a quit? It's even more confusing to say that C-g is a special event _unless_ it's been unread (perhaps transparently by something somewhere), in which case it's actually a regular event. > There's a > way around that, but the vast majority of callers don't need to worry > about it: (read-event) should read an ordinary event and return it, > without breaking quit. > >> Lisp isn't saying >> read-event-unless-it's-C-g-in-which-case-exit-non-locally. Lisp says >> read-event. > > That's implicit as for any other Lisp command that isn't specifically > documented not to quit. (As, for example, read-key-sequence is). Yes, and one or the other function should change, along with its documentation. What _reason_ is there to quit from one and not the other? >>> Anyway, here are the minor changes to keyboard.c to avoid the original >>> problem (the third change is somewhat independent and avoids quitting in >>> kbd_buffer_get_event): >> >> This change papers over the problem of ambiguous C-g representation > > It doesn't paper over anything. It merely quits before dequeueing > events when throw-on-input is in effect, without any major changes. > >> without trying to fix it or address the even worse problem of the quits >> going to the event loop and not being looked up as commands. > > Are you saying quits should *generally* be treated as commands rather > than by the event loop? Because my opinion is precisely the opposite: > quits should always be handled by C code, never by keyboard-quit, > because that's what they are used for: to break out of misbehaving Lisp > code, with minimal involvement of Lisp machinery which may be > misbehaving. _Quits_ are intended to break out of Lisp code, but C-g doesn't always mean quit. Transient, for example, uses C-g to dismiss its menus. execute-extended-command does too, as does completion. Like it or not, C-g is not merely a signal to Lisp to stop what it's doing, but also a legitimate event to which people bind regular commands, and it's a bug if we don't respect these bindings because in a certain circumstance invisible to users we decided that the C-g is really a stop-the-Lisp-world-now pseudo-error and not the user telling us he wants to run a command. > We'd need new, incompatible versions of almost all callers, because > those do want to quit when we hit C-g. And, again, we're taking away > the choice "act on C-g as usual", replacing it by a new "identify > (somehow) quit events and (somehow) quit when you see one". I haven't seen anything actually malfunction due to having (read-event) return C-g as an event instead of quitting, and some code actually expects it. Some code actually _works_ better. Consider, for example, calc-get-user-defn. (defun calc-get-user-defn () (interactive) (calc-wrapper (message "Get definition of command: z-") (let* ((key (read-char)) (def (or (assq key (calc-user-key-map)) (assq (upcase key) (calc-user-key-map)) (assq (downcase key) (calc-user-key-map)) (error "No command defined for that key"))) ...) If read-char returns \?C-g, the code above produces a _better_ message, "No command defined for that key" (which is the truth) where it used to just say "Quit". Even hairy code like kbd-macro-query works fine when read-char, read-event, and so on report C-g as an event. If you can find something that actually breaks when we do that, we can do something else, but so far, I haven't seen reporting C-g break anything and have seen it make things a bit better. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 14:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17496538859204 (code B ref 78737); Wed, 11 Jun 2025 14:59:02 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 14:58:05 +0000 Received: from localhost ([127.0.0.1]:50051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPMtw-0002OO-A6 for submit@debbugs.gnu.org; Wed, 11 Jun 2025 10:58:04 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:42532) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPMtt-0002Np-Dy for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 10:58:02 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=IaGihg6YDXbdiSeMh02uvW9UL7P3g5DEVKReeDflDe0=; b=pYBYHyl1QNsyJVK6iqI+yKvSg0 PoKAQCUGaqXBebLowAoI5DFDTOUqju4YYenj/Sq8EFBQvEt/fSrp57aAKnBa5tKb4uaHhTVrBhhJZ K/uo+LxciQ6YvP/9yP7bL64BHm+WZVK52fNVZXaOLCplO52OuEOHddC8FajIalUNYlaa4vjxqjg09 qhMW6r2uBpyOtlhacYjnTv3ZCtln+55Q4b5ekVQ5S0dPzyzPBiwrxRuB3eJkOxg91atW9acoqXcAw 0QK3CCjbBU0eoUdjIl++njlKgzKpw7EvI/s6EctSpL2xDYA0KPj7j/hGJMPCWSG4DhayJbIji61Yd vDbqhUwg==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPMsS-00BgDg-3A; Wed, 11 Jun 2025 10:56:32 -0400 From: Daniel Colascione In-Reply-To: <86v7p2gxlv.fsf@gnu.org> References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Wed, 11 Jun 2025 07:57:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Eli Zaretskii writes: >> From: Daniel Colascione >> Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >> Date: Wed, 11 Jun 2025 07:08:45 -0700 >> >> Why is it good that read-key-sequence swallows quits but not read-char? > > I don't know. No one does. maybe there's a good reason for it, maybe > there was one at some point but there isn't anymore, maybe it's just a > historical accident. > > But being unable to answer such questions doesn't mean changing the > behavior is safe. It usually is the other way around, in a program as > old and complex as |Emacs. > >> C-g is an event. Why should read-event (but not read-key-sequence?) >> translate one kind of input event (C-g) to an action (signal quit) but >> return other kinds of events as they're given? > > You consider this to be an inconsistency based only on the name of the > API. But that's not necessarily the whole contract of the API. It > doesn't need to be called get-char-quit-when-c-g to behave like it > does. > > Anyway, I think arguing about this aspect is not useful. My problem > is not theoretical, it is practical: how much will break due to these > changes, and how long will it take us to become aware of the breakage > and attempt fixing it? I went through all the uses of read-char, read-char-exclusively, and read-event in the tree and didn't find anything that'll break if we make these functions return C-g as an event. I did some things that worked marginally better, as I mentioned in my previous message. It's possible something breaks, but I haven't seen evidence of breakage yet. >> What specifically do you think might break here? > > Not in those toy examples, but in much larger programs where these are > used. > > And I know what will break. As I told, we don't have a good set of > tests for it. I only know that every time we changed something in > read_char and its ilk in recent years, we ended up with regressions. All the more reason to simplify its contract. >> The higher level function wants to read an event. That's exactly what >> this function does now. > >> So you're saying it's a good thing that the behavior of the code changes >> depending on whether it's compiled? > > No, I'm saying that in this case it could be minor enough and rare > enough to fail to outweigh the risks. > >> This whole area is full of bugs. Are we seriously in "fixing bugs is >> bad because something might change" territory? In a development branch? >> With a knob (for now) to revert to the old, broken behavior? > > See above: that's not what I'm saying. > >> One way to make the code more understandable is to >> make it consistent and clearly define its contract. When code has a >> regular structure, you don't need to keep a thousand special cases in >> your mind when working on it. Regularity allows you to substitute >> reason for memory. The code is pretty irregular right now. > > I agree, but when dealing with old and very complex code that > thousands of programs rely upon, we need to consider the risks of > changing the old behavior even if it is somewhat inconsistent. > Because sometimes an old, known, and minor problem is better than new, > unknown, and exciting ones. Yes, and for cases in which we're changing user-visible semantics in a way that'll break workflows --- like beginning-of-defun, perhaps --- then I agree with you. I don't think this particular change belongs to that category. I've looked for evidence that would change my mind and haven't found any yet. You're right that changes to the input loop are risky, but they're going to be necessary sooner or later anyway, so wouldn't you prefer to change simpler code? Along the same lines, we could get rid of getcjmp too. I'm not afraid of rationalizing the contract of read-event or tweaking any other part of keyboard.c, but that thing and quit_throw_to_read_char are extremely confusing and do scare me a bit --- all the more reason, in my mind, to get rid of them, like Gerd wanted to do years ago. When is the right time to do that? It's not like an Emacs 31 release is imminent. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 15:20:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174965516316905 (code B ref 78737); Wed, 11 Jun 2025 15:20:04 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 15:19:23 +0000 Received: from localhost ([127.0.0.1]:50237 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPNEY-0004Oa-US for submit@debbugs.gnu.org; Wed, 11 Jun 2025 11:19:23 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:20801) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPNEV-0004OE-QL for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 11:19:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749655152; x=1749914352; bh=d3CuElYG8/zsZWCOmO/z8hdXVH0bNRYgClwndTwSa7o=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=pcL2jBpLJP2If58qXlYV20iwHSjfWNh+1fiAUc3TAOdQLstAJUPHMLoYuAJtoUXkl Qb17Bsf/p2y6fG1p83rjSMwjFREH1jlfMqYip0XV6s0vaKJKg07tFPvWJFtv9yTB2b bLO6AJ5r83hsPFOoOwy4MKbwAuQMTxsVtwVaKGXgmySgW7wovF4DWgYkI1Dz0Xl/s5 5U4lmU0lDmRhaQyhlKgKAN/gWs4ze1LlJo78oJH5tJ7/mdHPXptQpVQ3vrigziwub0 Fcdd+EKXenBvDKgOd8yfvbz6gJKAg1xJI8jU6HAa55jBikWRHXFMuXZN+XySU2JcwY zVKhtmwBfh4yQ== Date: Wed, 11 Jun 2025 15:19:07 +0000 From: Pip Cet Message-ID: <875xh21f2w.fsf@protonmail.com> In-Reply-To: References: <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 715f9a178987bd59180b46cc6195ec2e1af0ed03 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Daniel Colascione" writes: > Eli Zaretskii writes: > >> We could also leave the old behavior alone. It isn't bad behavior. > > So you're saying it's a good thing that the behavior of the code changes > depending on whether it's compiled? You're right: that's not bad > behavior. It's abysmal behavior. Fixing the sit-for bug does not in any way require breaking quit. We should decide how we want to fix this bug, independently of considering major changes to the quitting mechanism in general. Binding inhibit-quit works; not removing events from the queue when we're about to quit works; re-queueing events from C would work, even though we'd need an extra flag to know how to requeue them so it'd be an API change. What would work best, IMHO, is a non-destructive way to wait for the next event. My suggestion would be: (while-no-input (sleep-for seconds)) That doesn't currently work in nested while-no-input because while-no-input nests the wrong way around (the outermost while-no-input should win, not the innermost one), but that's trivial to fix. diff --git a/lisp/subr.el b/lisp/subr.el index 729f8b3e09b..56575259ff9 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -3696,28 +3696,9 @@ sit-for (or nodisp (redisplay))) (t (or nodisp (redisplay)) - ;; FIXME: we should not read-event here at all, because it's much too - ;; difficult to reliably "undo" a read-event by pushing it onto - ;; unread-command-events. - ;; For bug#14782, we need read-event to do the keyboard-coding-system - ;; decoding (hence non-nil as second arg under POSIX ttys). - ;; For bug#15614, we need read-event not to inherit-input-method. - ;; So we temporarily suspend input-method-function. - (let ((read (let ((input-method-function nil)) - (read-event nil t seconds)))) - (or (null read) -=09 (progn - ;; https://lists.gnu.org/r/emacs-devel/2006-10/msg00394.html - ;; We want `read' appear in the next command's this-command-ev= ent - ;; but not in the current one. - ;; By pushing (cons t read), we indicate that `read' has not - ;; yet been recorded in this-command-keys, so it will be recor= ded - ;; next time it's read. - ;; And indeed the `seconds' argument to read-event correctly - ;; prevented recording this event in the current command's - ;; this-command-keys. -=09 (push (cons t read) unread-command-events) -=09 nil)))))) + (not (if throw-on-input + (sleep-for seconds) + (while-no-input (sleep-for seconds))))))) =20 (defun goto-char--read-natnum-interactive (prompt) "Get a natural number argument, optionally prompting with PROMPT. This appears to fix the original bug and the FIXME without any C changes, though we might have to hack sleep-for to prevent the hourglass from showing. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 15:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17496563282133 (code B ref 78737); Wed, 11 Jun 2025 15:39:01 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 15:38:48 +0000 Received: from localhost ([127.0.0.1]:50382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPNXL-0000YK-4o for submit@debbugs.gnu.org; Wed, 11 Jun 2025 11:38:48 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:40800) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPNXF-0000Xr-5N for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 11:38:42 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=rboljPkrOeMP/0wPAMQVpXlmGANvwPcyN0rXho8UCLM=; b=Fr4ntrbCrLe8wnzU4PuidoTsSx 7Ai88pffsvpzjVK5NRYF7J7Hh1NuIPF9a0yUfPxUKwatHkcQkKtzzx07UDC44WDs6yQJY5AeM5gSP bY4qhrTU0CIi5/Nfft+493C7ius7A2U3R7PPP/GGKTYXDAiyiSYUHJ8EsrEtpKRifpLrIQo92cTic SgbI+bT6dluFwi9kVrgNSAVK0G5KY689ClXKkbIHOBiACdxvrzolZV4H0F4ThdtuKIImUVQNTvv/+ sjtMDEJINO/8WQ6q1tw+Os1XEELHIQHUryLFx18izmATXPDsGpJqMGYT6tdHogFyY7bXfocXa9NXD n7hqyM/g==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPNVi-00BgU8-39; Wed, 11 Jun 2025 11:37:06 -0400 From: Daniel Colascione In-Reply-To: <875xh21f2w.fsf@protonmail.com> References: <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <875xh21f2w.fsf@protonmail.com> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Wed, 11 Jun 2025 08:38:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Pip Cet writes: > "Daniel Colascione" writes: > >> Eli Zaretskii writes: >> >>> We could also leave the old behavior alone. It isn't bad behavior. >> >> So you're saying it's a good thing that the behavior of the code changes >> depending on whether it's compiled? You're right: that's not bad >> behavior. It's abysmal behavior. > > Fixing the sit-for bug does not in any way require breaking quit. > > We should decide how we want to fix this bug, independently of > considering major changes to the quitting mechanism in general. > > Binding inhibit-quit works; not removing events from the queue when > we're about to quit works; re-queueing events from C would work, even > though we'd need an extra flag to know how to requeue them so it'd be an > API change. > > What would work best, IMHO, is a non-destructive way to wait for the > next event. > > My suggestion would be: > > (while-no-input (sleep-for seconds)) > > That doesn't currently work in nested while-no-input because > while-no-input nests the wrong way around (the outermost while-no-input > should win, not the innermost one), but that's trivial to fix. > > diff --git a/lisp/subr.el b/lisp/subr.el > index 729f8b3e09b..56575259ff9 100644 > --- a/lisp/subr.el > +++ b/lisp/subr.el > @@ -3696,28 +3696,9 @@ sit-for > (or nodisp (redisplay))) > (t > (or nodisp (redisplay)) > - ;; FIXME: we should not read-event here at all, because it's much too > - ;; difficult to reliably "undo" a read-event by pushing it onto > - ;; unread-command-events. > - ;; For bug#14782, we need read-event to do the keyboard-coding-system > - ;; decoding (hence non-nil as second arg under POSIX ttys). > - ;; For bug#15614, we need read-event not to inherit-input-method. > - ;; So we temporarily suspend input-method-function. > - (let ((read (let ((input-method-function nil)) > - (read-event nil t seconds)))) > - (or (null read) > - (progn > - ;; https://lists.gnu.org/r/emacs-devel/2006-10/msg00394.html > - ;; We want `read' appear in the next command's this-command-event > - ;; but not in the current one. > - ;; By pushing (cons t read), we indicate that `read' has not > - ;; yet been recorded in this-command-keys, so it will be recorded > - ;; next time it's read. > - ;; And indeed the `seconds' argument to read-event correctly > - ;; prevented recording this event in the current command's > - ;; this-command-keys. > - (push (cons t read) unread-command-events) > - nil)))))) > + (not (if throw-on-input > + (sleep-for seconds) > + (while-no-input (sleep-for seconds))))))) That's a good idea. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 16:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17496575669333 (code B ref 78737); Wed, 11 Jun 2025 16:00:03 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 15:59:26 +0000 Received: from localhost ([127.0.0.1]:50522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPNrJ-0002QL-2W for submit@debbugs.gnu.org; Wed, 11 Jun 2025 11:59:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49368) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPNrF-0002Pq-DB for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 11:59: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 1uPNr8-0000Br-Tv; Wed, 11 Jun 2025 11:59:14 -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=jNypfq1pF7XalAWP9OMOUa4HYlfINcpnr9bF3qaaTPA=; b=DjpV3JyK4BNs 5DG/IQU/pyGOlSEBhAtyheceNziNs8TpTbJDMctHix04Aow7I60rWhNdY3Bf9x1s9dKeU8QBLO84D zXwcs8sv5t7+5ierW46mL4kDA3oo9Qyn0YMGxSw9CcWA6LYKjshewiwAFko1PnqJVowStLyjV0IqE +j97F/gMajU2G5+Aq/1B4gA+IpaIWXtQF0PWI4viQnOI8ZvQYciy9ZF2FktIFUryd7Luw97QHKIDK MH9kofO3RnHznzBa3rXDAtXIgWz84Rx3HXHLsqERrE6qV3XNq7zrnEFiDx1BIzNtaZJw2GICM6vq1 UEePNYNjz7BqNUeWvQ0vtg==; Date: Wed, 11 Jun 2025 18:59:11 +0300 Message-Id: <86plfagtgw.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Wed, 11 Jun 2025 07:57:52 -0700) References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Daniel Colascione > Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > Date: Wed, 11 Jun 2025 07:57:52 -0700 > > Eli Zaretskii writes: > > > Anyway, I think arguing about this aspect is not useful. My problem > > is not theoretical, it is practical: how much will break due to these > > changes, and how long will it take us to become aware of the breakage > > and attempt fixing it? > > I went through all the uses of read-char, read-char-exclusively, and > read-event in the tree and didn't find anything that'll break if we make > these functions return C-g as an event. How did you look for potential problems? E.g., the C-g flow is impossible to see in the code, you need to try it; doing that in all the possible places where we use this stuff and with all the different timings is practically impossible, I think. The number of possible combinations of affected APIs with while-no-input and other stuff sensitive to this is also quite close to infinite. And then there are keyboard macros, input methods (which not all of them work the same with unread-command-events etc.) and more. > > And I know what will break. As I told, we don't have a good set of > > tests for it. I only know that every time we changed something in > > read_char and its ilk in recent years, we ended up with regressions. > > All the more reason to simplify its contract. If simplifying the contract removes support for valid use cases, we break something, and need to somehow restore it (after we discover what broke, which might take time). And who knows what new complexity that will bring us. But even if overall it means simplification, the energy invested in that is not free, and could be used in other areas of Emacs, where ROI is higher. > > I agree, but when dealing with old and very complex code that > > thousands of programs rely upon, we need to consider the risks of > > changing the old behavior even if it is somewhat inconsistent. > > Because sometimes an old, known, and minor problem is better than new, > > unknown, and exciting ones. > > Yes, and for cases in which we're changing user-visible semantics in a > way that'll break workflows --- like beginning-of-defun, perhaps --- > then I agree with you. I don't think this particular change belongs to > that category. Not sure I follow: response to keyboard input and C-g is pretty much in users' faces. Changes in it could well break workflows, when C-g has special meanings, like in C-s. > I've looked for evidence that would change my mind and > haven't found any yet. You're right that changes to the input loop are > risky, but they're going to be necessary sooner or later anyway, so > wouldn't you prefer to change simpler code? > > Along the same lines, we could get rid of getcjmp too. I'm not afraid > of rationalizing the contract of read-event or tweaking any other part > of keyboard.c, but that thing and quit_throw_to_read_char are extremely > confusing and do scare me a bit --- all the more reason, in my mind, to > get rid of them, like Gerd wanted to do years ago. When is the right > time to do that? It's not like an Emacs 31 release is imminent. It depends how you interpret "imminent". Once Emacs 30.2 is released (which should be soon), the emacs-31 release branch will be cut soon afterwards, and development of Emacs 31 is basically frozen after that, only bug fixes and last-minute changes of existing features are allowed. Fingers crossed, that should happen in 3 or 4 months. The release itself is probably at least 6 months after that, but we can no longer make breaking changes during that period. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 16:37:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174965977422465 (code B ref 78737); Wed, 11 Jun 2025 16:37:03 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 16:36:14 +0000 Received: from localhost ([127.0.0.1]:50772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPOQs-0005pj-LU for submit@debbugs.gnu.org; Wed, 11 Jun 2025 12:36:14 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:50314) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPOQg-0005nH-RB for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 12:36:07 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=LXph/lIok3EE0R2rHgDs8JPDrHXzZ6dNfr4/PWtnVQE=; b=Lq2DKK4DjExvwhkObZFCry+caZ +Xv8dEmhcZf+BHfn4LgarR2Rv2b19a6faamlBD1oNu/l6o61QwIHN+pyYOVxVLrbqjGcgrBZlY+9N g13/klBoxRPxXljPfSp5EcCIw/a8riPmR4KAxlFJyBLVdzGDKOKGDkNYqwuR7QMhg3A4fJNX8XFyU yNKkoYiXxxk47JiZve8vHYkFsoB6VXyiPbRBQyBb8Gx+zOZOz7yvYKlNFnKyu/GNi5fjrhyuAspJw 0p0P/1OnsfmXk28zIWiiezI5Chenk2bJJg+EpOR5Aa3bqJ9GOpoRR+a1qYVi9muJrKYXjQPg27iUH MUQVMbKA==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPOPE-00Bh5q-2E; Wed, 11 Jun 2025 12:34:28 -0400 From: Daniel Colascione In-Reply-To: <86plfagtgw.fsf@gnu.org> References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <86plfagtgw.fsf@gnu.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Wed, 11 Jun 2025 09:35:48 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Eli Zaretskii writes: >> From: Daniel Colascione >> Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >> Date: Wed, 11 Jun 2025 07:57:52 -0700 >> >> Eli Zaretskii writes: >> >> > Anyway, I think arguing about this aspect is not useful. My problem >> > is not theoretical, it is practical: how much will break due to these >> > changes, and how long will it take us to become aware of the breakage >> > and attempt fixing it? >> >> I went through all the uses of read-char, read-char-exclusively, and >> read-event in the tree and didn't find anything that'll break if we make >> these functions return C-g as an event. > > How did you look for potential problems? E.g., the C-g flow is > impossible to see in the code, you need to try it; doing that in all > the possible places where we use this stuff and with all the different > timings is practically impossible, I think. I tried everything (e.g. kbd-macro-query) where the effect wasn't obvious from the code. And I'm not sure what "timings" you're talking about here: read-char, etc. will now _deterministically_ return \?C-g on quit, so there's no timing involved. For the broader change to quit, well, I've been using the thing and have seen no problems. isearch works fine. Macros work fine. minibuffer-quit in a macro works just as it did before too. Input methods work fine --- at least greek, russian-typewriter, and Chinese 4-corners. Any others you think might be particularly hairy? With the exception of read-char, read-char-exclusively, and read-event, the Lisp API contract hasn't changed: wherever we would previously run the command bound to C-g most of the time, we now run all the time. That's not going to break anything: we're merely taking something that was 1) supposed to happen, and 2) usually did happen, and make it happen in all the cases users expect it to happen. Keep in mind that you've always been able to bind commands to C-g: it's just that previously, C-g would occasionally fail to invoke these commands. Now it does. Quit in redisplay is now inhibited by default, but you said that was a bad idea to allow in the first place. Lisp quits work normally. Better, actually: the NS port now even reliably quits where it's supposed to quit. The debugger works fine. edebug works too. debug-on-quit works. Recursive edits --- no difference. The C-g eating test I've been using is to start a (compile "cat /dev/urandom") and try to interact with Emacs. Previously, the Emacs command loop would eat tons of C-g presses as quits during this stress test instead of running the command bound to C-g: now we reliably run the bound command. I've run the same test under a TTY too. Works fine. Transient, execute-extended-command, and other things that bind commands to C-g all work fine and more reliably. Quitting in minibuffer read still works fine, even when we have a message popup like "complete but not unique". sit-for works fine. while-no-input works fine: better now that it doesn't drop events. I'm really not seeing what there is to be worried about. I'm especially not worried about timing considering that we've made the system more deterministic and reduced the number of timing-related bugs we might have had. I'll add the kill switch you wanted. I don't think it's necessary, but it's not going to do any harm. Other than this kill switch and making sure SIGUSR2 quits out of read-event, it seems fine to me. > > The number of possible combinations of affected APIs with > while-no-input and other stuff sensitive to this is also quite close > to infinite. And then there are keyboard macros, input methods (which > not all of them work the same with unread-command-events etc.) and > more. > >> > And I know what will break. As I told, we don't have a good set of >> > tests for it. I only know that every time we changed something in >> > read_char and its ilk in recent years, we ended up with regressions. >> >> All the more reason to simplify its contract. > > If simplifying the contract removes support for valid use cases It doesn't remove support for any use cases. It regularizes the API and the implementation. There are no lost capabilities. The contract of read_char (the C function, not to be confused with read-char the Lisp function, which is confusingly totally different) has changed to not internally quit, bu. > we > break something, and need to somehow restore it (after we discover > what broke, which might take time). One can imagine unlimited unknown unknowns. > And who knows what new complexity > that will bring us. But even if overall it means simplification, the > energy invested in that is not free, and could be used in other areas > of Emacs, where ROI is higher. Energy isn't fungible. >> > I agree, but when dealing with old and very complex code that >> > thousands of programs rely upon, we need to consider the risks of >> > changing the old behavior even if it is somewhat inconsistent. >> > Because sometimes an old, known, and minor problem is better than new, >> > unknown, and exciting ones. >> >> Yes, and for cases in which we're changing user-visible semantics in a >> way that'll break workflows --- like beginning-of-defun, perhaps --- >> then I agree with you. I don't think this particular change belongs to >> that category. > > Not sure I follow: response to keyboard input and C-g is pretty much > in users' faces. Changes in it could well break workflows, when C-g > has special meanings, like in C-s. The only thing users will notice is Emacs behaving more predictably, and in the case of the NS port, being more responsive to quits. We're not talking about something in users' faces. >> I've looked for evidence that would change my mind and >> haven't found any yet. You're right that changes to the input loop are >> risky, but they're going to be necessary sooner or later anyway, so >> wouldn't you prefer to change simpler code? >> >> Along the same lines, we could get rid of getcjmp too. I'm not afraid >> of rationalizing the contract of read-event or tweaking any other part >> of keyboard.c, but that thing and quit_throw_to_read_char are extremely >> confusing and do scare me a bit --- all the more reason, in my mind, to >> get rid of them, like Gerd wanted to do years ago. When is the right >> time to do that? It's not like an Emacs 31 release is imminent. > > It depends how you interpret "imminent". Once Emacs 30.2 is released > (which should be soon), the emacs-31 release branch will be cut soon > afterwards, and development of Emacs 31 is basically frozen after > that, only bug fixes and last-minute changes of existing features are > allowed. Fingers crossed, that should happen in 3 or 4 months. The > release itself is probably at least 6 months after that, but we can no > longer make breaking changes during that period. 3-4 months is plenty of time for testing. If it doesn't smell right by then, it doesn't have to be in Emacs 31. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 19:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174966967417475 (code B ref 78737); Wed, 11 Jun 2025 19:22:02 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 19:21:14 +0000 Received: from localhost ([127.0.0.1]:51730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPR0c-0004Xn-68 for submit@debbugs.gnu.org; Wed, 11 Jun 2025 15:21:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42180) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPR0Z-0004XY-LO for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 15:21:12 -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 1uPR0T-0000lW-JB; Wed, 11 Jun 2025 15:21:05 -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=KjBEHCWLewOQFTe2H/JSDhtuOQnB5bXue7xcaK2NVJo=; b=grw5kSpv6UIC 32rfSoeMb1TNqJ82G8zsMMmIWpJfPtvhyes/x/e+37GmEBJWATXJZJnflnhP2itWkuIkmF8aShpK4 MfSzoK8aJyvPGJGdbrNSOpSZo1ze1gzd01CLSdYrJUaD3BFwTaZVdOKsJN1M+5W2GvtxTdf/jJl4L Z+WmRS87xUM29xFgsiHtLVRgM2usX+A422agAgJieWqDj/ejm4cZZ3EybzvGo9phr+GqT4s6J7G7F L8haFkkmJZxsnbm77C+n46eZV+TqNwf3N93x38AYAn/4JRvlT0GVjh2jPf91NDcp0KJvJ5OUkevg9 65tTluc3DehRNWe8FFnh9A==; Date: Wed, 11 Jun 2025 22:21:00 +0300 Message-Id: <86o6uugk4j.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Wed, 11 Jun 2025 09:35:48 -0700) References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <86plfagtgw.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Daniel Colascione > Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > Date: Wed, 11 Jun 2025 09:35:48 -0700 > > Eli Zaretskii writes: > > >> I went through all the uses of read-char, read-char-exclusively, and > >> read-event in the tree and didn't find anything that'll break if we make > >> these functions return C-g as an event. > > > > How did you look for potential problems? E.g., the C-g flow is > > impossible to see in the code, you need to try it; doing that in all > > the possible places where we use this stuff and with all the different > > timings is practically impossible, I think. > > > I tried everything (e.g. kbd-macro-query) where the effect wasn't > obvious from the code. And I'm not sure what "timings" you're talking > about here: read-char, etc. will now _deterministically_ return \?C-g on > quit, so there's no timing involved. I mean with the current code: C-g pressed at different times could produce different effects. > For the broader change to quit, well, I've been using the thing and have > seen no problems. isearch works fine. Macros work fine. > minibuffer-quit in a macro works just as it did before too. The problem with this stuff, in our experience, is that different people use different setups and workflows, and problems tend to depend on that. Which is why it takes time until they get reported. > Input methods work fine --- at least greek, russian-typewriter, and > Chinese 4-corners. Any others you think might be particularly hairy? Some of the East Asian, perhaps. Also, using input methods as part of recording keyboard macros caused trouble at some point. > With the exception of read-char, read-char-exclusively, and read-event, > the Lisp API contract hasn't changed: wherever we would previously run > the command bound to C-g most of the time, we now run all the time. > That's not going to break anything: we're merely taking something that > was 1) supposed to happen, and 2) usually did happen, and make it happen > in all the cases users expect it to happen. Keep in mind that you've > always been able to bind commands to C-g: it's just that previously, C-g > would occasionally fail to invoke these commands. Now it does. What about the effect of quit-flag? > Lisp quits work normally. Better, actually: the NS port now even > reliably quits where it's supposed to quit. The debugger works fine. > edebug works too. debug-on-quit works. Recursive edits --- > no difference. What about C-g on Unix TTYs? Including when there are additional Lisp threads? > I'll add the kill switch you wanted. I don't think it's necessary, but > it's not going to do any harm. Other than this kill switch and making > sure SIGUSR2 quits out of read-event, it seems fine to me. We should ask more people to try the branch, especially on other platforms. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Jun 2025 21:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174967831528901 (code B ref 78737); Wed, 11 Jun 2025 21:46:02 +0000 Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 21:45:15 +0000 Received: from localhost ([127.0.0.1]:52613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPTFy-0007Vg-Un for submit@debbugs.gnu.org; Wed, 11 Jun 2025 17:45:15 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:38220) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPTFw-0007TA-7Y for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 17:45:13 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=N7ynpUYLwDBcHfsMNze8ZclA6dGaBffx1lRoXgnCdLA=; b=iNdA0bgtwKKFqoVXcEz2ivR6L7 nI0vS1wWuK8rPUIVi2CBfD9WW+PKxCybjqBrMqjuUJLXfvTNxTJl53dXteeMXyQWBoOUa+kR9nNB6 F4SLUb39rGbrs5bvRrsX0y71zWhf+SUesRqolhf+8M3AR4b2ugaWLJxl9KMlg6OeTxgI7HZGYhWrG 2TZ1Q/ncgrEr4k4qbBDVHJCLcK4PUI5Aw+zrgK5zC8HXDjX+iqz2DVEbfcfnTbcL3KZVOxv2BfPrx kKITNgFvwhzYYJ9G1tT0ey4DixCE8Aqreg441D9bKQCHrqdoy/qjBNLdVQsDgJx94g8miY2B0/8er 163q9IQQ==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPTEP-00BiJc-1t; Wed, 11 Jun 2025 17:43:37 -0400 From: Daniel Colascione In-Reply-To: <86o6uugk4j.fsf@gnu.org> References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <86plfagtgw.fsf@gnu.org> <86o6uugk4j.fsf@gnu.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Wed, 11 Jun 2025 14:44:57 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Eli Zaretskii writes: >> From: Daniel Colascione >> Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >> Date: Wed, 11 Jun 2025 09:35:48 -0700 >> >> Eli Zaretskii writes: >> >> >> I went through all the uses of read-char, read-char-exclusively, and >> >> read-event in the tree and didn't find anything that'll break if we make >> >> these functions return C-g as an event. >> > >> > How did you look for potential problems? E.g., the C-g flow is >> > impossible to see in the code, you need to try it; doing that in all >> > the possible places where we use this stuff and with all the different >> > timings is practically impossible, I think. >> >> >> I tried everything (e.g. kbd-macro-query) where the effect wasn't >> obvious from the code. And I'm not sure what "timings" you're talking >> about here: read-char, etc. will now _deterministically_ return \?C-g on >> quit, so there's no timing involved. > > I mean with the current code: C-g pressed at different times could > produce different effects. Given that these "different times" have been nondeterministic and that there's no legitimate reason a program would rely on them, I don't see our having introduced any timing issues, and none have shown up in my tests. >> For the broader change to quit, well, I've been using the thing and have >> seen no problems. isearch works fine. Macros work fine. >> minibuffer-quit in a macro works just as it did before too. > > The problem with this stuff, in our experience, is that different > people use different setups and workflows, and problems tend to depend > on that. Which is why it takes time until they get reported. In theory, Hyrum's law can bite you any time, but I'm just not seeing behavior depend on a timing bug. The read-event contract could in theory break someone, but I still haven't seen evidence of it actually happening. >> Input methods work fine --- at least greek, russian-typewriter, and >> Chinese 4-corners. Any others you think might be particularly hairy? > > Some of the East Asian, perhaps. Also, using input methods as part of > recording keyboard macros caused trouble at some point. There's one East Asian input method in the list already. >> With the exception of read-char, read-char-exclusively, and read-event, >> the Lisp API contract hasn't changed: wherever we would previously run >> the command bound to C-g most of the time, we now run all the time. >> That's not going to break anything: we're merely taking something that >> was 1) supposed to happen, and 2) usually did happen, and make it happen >> in all the cases users expect it to happen. Keep in mind that you've >> always been able to bind commands to C-g: it's just that previously, C-g >> would occasionally fail to invoke these commands. Now it does. > > What about the effect of quit-flag? Nothing about the meaning of quit-flag has changed. >> Lisp quits work normally. Better, actually: the NS port now even >> reliably quits where it's supposed to quit. The debugger works fine. >> edebug works too. debug-on-quit works. Recursive edits --- >> no difference. > > What about C-g on Unix TTYs? Including when there are additional Lisp > threads? Unix TTYs work fine. Threads work as well as they ever have: both in master and on my branch, this puts Emacs into an unresponsive and unquittable state: (make-thread (lambda () (while t)) "spinner") At least it's not a regression. Basic accept-process-output with a reasonable timeout on a thread works fine and doesn't interfere with interactive quitting and other UI interactions. > >> I'll add the kill switch you wanted. I don't think it's necessary, but >> it's not going to do any harm. Other than this kill switch and making >> sure SIGUSR2 quits out of read-event, it seems fine to me. > > We should ask more people to try the branch, especially on other > platforms. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Lynn Winebarger Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 01:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174969021812381 (code B ref 78737); Thu, 12 Jun 2025 01:04:01 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 01:03:38 +0000 Received: from localhost ([127.0.0.1]:54155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPWLy-0003Dd-4p for submit@debbugs.gnu.org; Wed, 11 Jun 2025 21:03:38 -0400 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:40235) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uPWLv-0003DI-Lj for 78737@debbugs.gnu.org; Wed, 11 Jun 2025 21:03:36 -0400 Received: by mail-wr1-x434.google.com with SMTP id ffacd0b85a97d-3a4e57d018cso62517f8f.1 for <78737@debbugs.gnu.org>; Wed, 11 Jun 2025 18:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749690209; x=1750295009; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fZ2eHRINcXhLcWD2IF4e7RDGbXu+Y/2R6DnGDXFKvwM=; b=NBqAI2yvn2EWLAL7d0llIijNv9FI8GMXShn1uJrai1oki9T3zLjQKd4LtP76FefUVh lbYiIkEURPI8feo3NTaAKQ7dA+IBc5PfYpywkyCYCYzOXjBBWhAJYl1IRUDBOlz7to0t Sw3RTWp7/KhnHx0UzSP7q5Rc1TaY7YRQvvbUlQiGvQnqyb2Oxjq1tR8bTvlyqplyuBm/ Qps7c3oDMpFz0EJJq1fb6D+7P8Hw/soMpST9YvHodGHF01P+YI6upG0nGohm8kNGTyZr +j5dRt4E8jiZLtOVXwjQ8NmLY0IiNjA+PpCXzYOrImeZeayyCvDyEql3QcPgZDCeAbng pxlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749690209; x=1750295009; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fZ2eHRINcXhLcWD2IF4e7RDGbXu+Y/2R6DnGDXFKvwM=; b=az07rj5/Z08zIsMPq+ncOjbEum2b5dQECsJ+VeTNFiLSfPCvS8w+W2uJQTNmip8CPc tSJndOvwvuohNz9eXWGMxs2QK2Ig2HUPbUh98v8o4OIQJTSkLbjhbOPV9tr1lakAo9Mq Li8poY3xo52ZEn5eR4OlOoz8morsbAAUK9TKO/PQIk/bO7gc2zWdJ63CZfYRH77bLtng Vt3CYmIIEIbxt45ck1NSWElg93yrCeoWxWmoL8YPDp7Qv4OHGPbM+l7+xGzTqTimXKRm XpHVE0TWwMBFhGvqhpzgs/hXvCw70B4rFJtEEGON8C/qlx1tgkhp9EXU0oo6/W+Fd1w+ ttHQ== X-Forwarded-Encrypted: i=1; AJvYcCUXJRhAxh34ImNGqa910u8f1KlE2sJ0qJ382lr5UraHvcya9qK2ciEqHrXHeX67HYW9C2Hn/w==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yy4OHlMrGg3XOM/PLbdVhDW63JTodha2hnTT9hWG9PXLgTxNna5 2MzXgzHd3HjrLh8uH68zZAIqY0njSDLuMrNP3Zy+Tg40Uf/Gw9SKUVMGUyFxcPdjrA2uIFApjFG Xt/DL9GMKtHHkWXTANpM2y4NuyVA5JTE= X-Gm-Gg: ASbGnctctkuVOv1xE+7Mmh7ffe3WATj2/z5iPhj4hUxTqxKPuQ4U+e0Ux3B5Wa8teDd myOgXFwkYhl9UAzVp6DARh7c/dyPnzq4ZFeiCF9gIo+3v+z/BsFTGXzh40njLt7BmKTNdzsa5Kv nQOug6Wdtj8x1Ft/4n3AGJJgrrUrK3KkUM+E7fnUWcMp29c4murqUXyzXDVNAaAO1oK4I= X-Google-Smtp-Source: AGHT+IE+NhapGr43pGblrXnfQ0Pe9xZbLHaat5ov38bM1+niQDKNiG/gh2IZspp9dmwE27zl78CaXufmqMSTre78doo= X-Received: by 2002:a05:6000:26c1:b0:3a5:3369:52f3 with SMTP id ffacd0b85a97d-3a5586bd299mr1510619f8f.3.1749690208977; Wed, 11 Jun 2025 18:03:28 -0700 (PDT) MIME-Version: 1.0 References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <86plfagtgw.fsf@gnu.org> In-Reply-To: From: Lynn Winebarger Date: Wed, 11 Jun 2025 21:03:17 -0400 X-Gm-Features: AX0GCFv_myLz5HqskkeQAeDOEC0fo3Da5W9yxvZ1-iIoL1bgyEZbibRdnxIzNAs Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 Wed, Jun 11, 2025 at 12:37=E2=80=AFPM Daniel Colascione wrote: > The contract of > read_char (the C function, not to be confused with read-char the Lisp > function, which is confusingly totally different) [...] You are so right, but don't forget the bypassing of the function cell for Qread_char in Fread to hardwire a call to Qread_minibuffer instead. Lynn From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 05:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174970574726540 (code B ref 78737); Thu, 12 Jun 2025 05:23:02 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 05:22:27 +0000 Received: from localhost ([127.0.0.1]:55132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPaOQ-0006tz-Lf for submit@debbugs.gnu.org; Thu, 12 Jun 2025 01:22:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34448) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPaON-0006tc-MK for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 01:22:25 -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 1uPaOF-000062-GF; Thu, 12 Jun 2025 01:22: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=xmqwpicREkRj+BLElYiuatzeMZqztdi+xxXYQ4MFoYg=; b=sZQa1ySuWH/C YPgTO5FzmCExqXmHG+mECktJhlRgP/Df6aSPRBB5CYq7ZtzaXDfxr/XIvp0vYW8N5iGNS25X2wxra 2XcUF/EeTzeSZn1vxddFSRlMuOfa78H3m/ztZdw0ThL872YPeuprjwunzpF8XciUa2E5JTUlvxCcB 2cX3NbTR+M8+ZDHjiATlcDbohfeL3OqqFS1ELY273AfbgFPhmbKHPoCUCwPmxgIMm6++50tR4C5pe dSh1IJz128TmeOAPyB3AJZXZfmLZuWLCEh+VgIsD5TW5XYucfCMstv6vHlcFmrIK0zClZvLtzeY4R s45Z229TBvxDlbOZoSwSVg==; Date: Thu, 12 Jun 2025 08:22:10 +0300 Message-Id: <86frg5h6v1.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Wed, 11 Jun 2025 14:44:57 -0700) References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <86plfagtgw.fsf@gnu.org> <86o6uugk4j.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Daniel Colascione > Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > Date: Wed, 11 Jun 2025 14:44:57 -0700 > > >> I tried everything (e.g. kbd-macro-query) where the effect wasn't > >> obvious from the code. And I'm not sure what "timings" you're talking > >> about here: read-char, etc. will now _deterministically_ return \?C-g on > >> quit, so there's no timing involved. > > > > I mean with the current code: C-g pressed at different times could > > produce different effects. > > Given that these "different times" have been nondeterministic and that > there's no legitimate reason a program would rely on them, I don't see > our having introduced any timing issues, and none have shown up in > my tests. Time will tell. IME, these assumptions tend to break, at least sometimes. > >> For the broader change to quit, well, I've been using the thing and have > >> seen no problems. isearch works fine. Macros work fine. > >> minibuffer-quit in a macro works just as it did before too. > > > > The problem with this stuff, in our experience, is that different > > people use different setups and workflows, and problems tend to depend > > on that. Which is why it takes time until they get reported. > > In theory, Hyrum's law can bite you any time, but I'm just not seeing > behavior depend on a timing bug. The read-event contract could in > theory break someone, but I still haven't seen evidence of it > actually happening. I hear you. I'm just saying that if experience has taught us anything in this area, it's that we should encourage as many people as possible on as many different platforms as possible to try the new code and report back. > >> Input methods work fine --- at least greek, russian-typewriter, and > >> Chinese 4-corners. Any others you think might be particularly hairy? > > > > Some of the East Asian, perhaps. Also, using input methods as part of > > recording keyboard macros caused trouble at some point. > > There's one East Asian input method in the list already. Yes, but they work differently, so a few more won't hurt. > >> With the exception of read-char, read-char-exclusively, and read-event, > >> the Lisp API contract hasn't changed: wherever we would previously run > >> the command bound to C-g most of the time, we now run all the time. > >> That's not going to break anything: we're merely taking something that > >> was 1) supposed to happen, and 2) usually did happen, and make it happen > >> in all the cases users expect it to happen. Keep in mind that you've > >> always been able to bind commands to C-g: it's just that previously, C-g > >> would occasionally fail to invoke these commands. Now it does. > > > > What about the effect of quit-flag? > > Nothing about the meaning of quit-flag has changed. You mean, you didn't intend for it to change, right? But the changes on the branch definitely access and set it in several places, so it _could_ change, albeit inadvertently. Thus, I think it would be good to test that as well. The test suite uses inhibit-quit in 2 places, so maybe run those tests, both interactively and noninteractively? Also, searching the tree for "quit-flag" comes up with a few dozen matches, so maybe look into those places and see if they still work as expected? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 13:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17497349694304 (code B ref 78737); Thu, 12 Jun 2025 13:30:03 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 13:29:29 +0000 Received: from localhost ([127.0.0.1]:57436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPhzk-00017L-Sn for submit@debbugs.gnu.org; Thu, 12 Jun 2025 09:29:29 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:50592) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPhzi-000176-0S for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 09:29:27 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=jrxKq6l7/TVUpTtX6/dUCrspxBoY1bDWQg4fAhiofCs=; b=aMiDUS6UwcsVapKpTjkpeAxWUU qpuvBfcdQCrG3bppxmszW0pgtz5a1y44zK7o6g1345+fsOoa7xxpRLq8VjkMG1VPXEQ6XMoYnjJ12 6UcZH+b3RhPHTSV/53DOow+f0pNV04AXYpO1uj3SkFHxyXKYINEX/lqWZlVanRGpPhvOE1TFMuFtk /IjtC/Ryk7nta47jfdOqvDgxq3CgjoDFR4nnB56Ando/mZ5qzVtI4zJG8WLauY0M5TB+Qw4kPsaCo cDY4BCIlzGMfP5XhkL1CXbWSgvlE1QdH8BMMxQjHyiPSjqFXZMEbmRK4keeOXG1ehuvToMz0/oGeV XrrQT7Vw==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPhyC-00BlRJ-1x; Thu, 12 Jun 2025 09:27:52 -0400 From: Daniel Colascione In-Reply-To: <86frg5h6v1.fsf@gnu.org> References: <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <86plfagtgw.fsf@gnu.org> <86o6uugk4j.fsf@gnu.org> <86frg5h6v1.fsf@gnu.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Thu, 12 Jun 2025 06:29:13 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Eli Zaretskii writes: >> From: Daniel Colascione >> Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >> Date: Wed, 11 Jun 2025 14:44:57 -0700 >> >> >> I tried everything (e.g. kbd-macro-query) where the effect wasn't >> >> obvious from the code. And I'm not sure what "timings" you're talking >> >> about here: read-char, etc. will now _deterministically_ return \?C-g on >> >> quit, so there's no timing involved. >> > >> > I mean with the current code: C-g pressed at different times could >> > produce different effects. >> >> Given that these "different times" have been nondeterministic and that >> there's no legitimate reason a program would rely on them, I don't see >> our having introduced any timing issues, and none have shown up in >> my tests. > > Time will tell. IME, these assumptions tend to break, at least > sometimes. > > >> For the broader change to quit, well, I've been using the thing and have >> >> seen no problems. isearch works fine. Macros work fine. >> >> minibuffer-quit in a macro works just as it did before too. >> > >> > The problem with this stuff, in our experience, is that different >> > people use different setups and workflows, and problems tend to depend >> > on that. Which is why it takes time until they get reported. >> >> In theory, Hyrum's law can bite you any time, but I'm just not seeing >> behavior depend on a timing bug. The read-event contract could in >> theory break someone, but I still haven't seen evidence of it >> actually happening. > > I hear you. I'm just saying that if experience has taught us anything > in this area, it's that we should encourage as many people as possible > on as many different platforms as possible to try the new code and > report back. > >> >> Input methods work fine --- at least greek, russian-typewriter, and >> >> Chinese 4-corners. Any others you think might be particularly hairy? >> > >> > Some of the East Asian, perhaps. Also, using input methods as part of >> > recording keyboard macros caused trouble at some point. >> >> There's one East Asian input method in the list already. > > Yes, but they work differently, so a few more won't hurt. > >> >> With the exception of read-char, read-char-exclusively, and read-event, >> >> the Lisp API contract hasn't changed: wherever we would previously run >> >> the command bound to C-g most of the time, we now run all the time. >> >> That's not going to break anything: we're merely taking something that >> >> was 1) supposed to happen, and 2) usually did happen, and make it happen >> >> in all the cases users expect it to happen. Keep in mind that you've >> >> always been able to bind commands to C-g: it's just that previously, C-g >> >> would occasionally fail to invoke these commands. Now it does. >> > >> > What about the effect of quit-flag? >> >> Nothing about the meaning of quit-flag has changed. > > You mean, you didn't intend for it to change, right? But the changes > on the branch definitely access and set it in several places, so it > _could_ change, albeit inadvertently. Thus, I think it would be good > to test that as well. The test suite uses inhibit-quit in 2 places, > so maybe run those tests, both interactively and noninteractively? > Also, searching the tree for "quit-flag" comes up with a few dozen > matches, so maybe look into those places and see if they still work as > expected? I've already tried everything that AFAICT might reasonably have broken as a result of the change, including its use of quit-flag, and didn't see anything wrong. I've been using the thing too. I'd expect that if I'd broken something fundamental, bugs would have shown up by now. But sure, let's test the branch and see whether anyone else can find something wrong. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 14:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174973674912782 (code B ref 78737); Thu, 12 Jun 2025 14:00:02 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 13:59:09 +0000 Received: from localhost ([127.0.0.1]:59034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPiSS-0003K5-L2 for submit@debbugs.gnu.org; Thu, 12 Jun 2025 09:59:09 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:17329) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPiSM-0003JO-0q for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 09:59:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749736735; x=1749995935; bh=YRXoVFxOndif2lS6HXGHLOdDZ7AZn+41F/OOgBLP96k=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=pF2wU+As8PQh7WrjZ7pMFVzyzA9EE0lEadUPsFZAfeU5pZzHQc75p1s0mM4XQ9fK+ +Y/x6wBCVSzDLJaN9i7e06/cTmuCBZcKkaqqystfkIsYgUjceIlr/vFyltsDWkXcQF lweEBlBwvV5sJC4zTzW8+j3d9Se+BQw0y9xa6CWJCD1a1GRHTrznkK+ZE/LaY8Nn3O iILW+IkJOW5k70p2Y1+DoQPq2/Wthd49+SlwHLFsHzS+LI8UTwdIzdUqlpvJJYHU7O ILWYf6sfYy+XrSiI+4X0Y2z5SeQCQ+k4eDomjD6CoWRCf5dStSjWgw+HDJM5b8Xu9p oghvRDt0IwRRA== Date: Thu, 12 Jun 2025 13:58:51 +0000 From: Pip Cet Message-ID: <87sek5ysbs.fsf@protonmail.com> In-Reply-To: References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c0105d39f6cbff6f97ef3cfa0c35d206c237165e MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Daniel Colascione" writes: > Eli Zaretskii writes: > >>> From: Daniel Colascione >>> Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gn= u.org >>> Date: Wed, 11 Jun 2025 07:08:45 -0700 >>> >>> Why is it good that read-key-sequence swallows quits but not read-char? >> >> I don't know. No one does. maybe there's a good reason for it, maybe >> there was one at some point but there isn't anymore, maybe it's just a >> historical accident. >> >> But being unable to answer such questions doesn't mean changing the >> behavior is safe. It usually is the other way around, in a program as >> old and complex as |Emacs. >> >>> C-g is an event. Why should read-event (but not read-key-sequence?) >>> translate one kind of input event (C-g) to an action (signal quit) but >>> return other kinds of events as they're given? >> >> You consider this to be an inconsistency based only on the name of the >> API. But that's not necessarily the whole contract of the API. It >> doesn't need to be called get-char-quit-when-c-g to behave like it >> does. >> >> Anyway, I think arguing about this aspect is not useful. My problem >> is not theoretical, it is practical: how much will break due to these >> changes, and how long will it take us to become aware of the breakage >> and attempt fixing it? > > I went through all the uses of read-char, read-char-exclusively, and > read-event in the tree and didn't find anything that'll break if we make > these functions return C-g as an event. I did some things that worked The first thing I looked at was mouse-drag-secondary. It breaks (not too badly: it just loses a quit event, but it's still an undesirable change in behavior). > marginally better, as I mentioned in my previous message. It's possible > something breaks, but I haven't seen evidence of breakage yet. I'd say breaking (read-event) called in a loop is bad enough, because how else are you supposed to start developing code which uses it? > Yes, and for cases in which we're changing user-visible semantics in a > way that'll break workflows --- like beginning-of-defun, perhaps --- > then I agree with you. I don't think this particular change belongs to > that category. I've looked for evidence that would change my mind and > haven't found any yet. You're right that changes to the input loop are > risky, but they're going to be necessary sooner or later anyway, so > wouldn't you prefer to change simpler code? Since we've progressed to testing the branch, with the implication being that we'll merge it soon, it may be too late to make alternative suggestions. In case it's not, though: I think this discussion is concerned too much with what existing code will break if we change quit not to quit, not enough with how much more difficult it will be to develop code if we do, and not at all, so far, with what the advantages of handling quit in Lisp (if Lisp decides to handle it at all) are. C-g isn't an input event in the same way that kicking someone in the shin is not a dance move. I want it to kick Emacs in the shin, and break out of bad Lisp code, in *more* situations than it does now. That would simplify things, and give us a more powerful quit rather than one subject to innocent mistakes in Lisp code that looks just fine. The "C-g quits" rule would simply take precedence over all other input handling rules, simplifying the contract if that's what you think of it as. People who don't want quit to quit could then call (set-quit-char nil) or something similar and reuse the quit character for something else. Something like that should be the only way to disable this extremely useful feature, though. We could even make it the default behavior and let people who want quit put it in their init files. Independently of all this, we should change our triple C-g detection to work in cases where a Lisp user or keyboard.c clears quit-flag without actually handling the quit. If we change things so C-g is ordinary input, we can at least limit the damage and let people use triple C-g in the unquittable infloops that will result (triple C-g isn't safe and you should restart your Emacs session after using it, but that's less inconvenient than losing the entire session). Maybe a compromise would be to continue the arms race and downgrade C-g to normal input, C-g C-g C-g to a quit, and require even more C-g's for a force-quit? > Along the same lines, we could get rid of getcjmp too. I'm not afraid > of rationalizing the contract of read-event or tweaking any other part > of keyboard.c, but that thing and quit_throw_to_read_char are extremely > confusing and do scare me a bit --- all the more reason, in my mind, to > get rid of them, like Gerd wanted to do years ago. When is the right > time to do that? It's not like an Emacs 31 release is imminent. I think that's a different discussion, to be honest. getcjmp should be changed, definitely: it's currently updated non-atomically using memcpy, which means we might longjmp to an inconsistent jmp_buf from a signal handler and crash, IIUC. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 14:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174973898922716 (code B ref 78737); Thu, 12 Jun 2025 14:37:02 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 14:36:29 +0000 Received: from localhost ([127.0.0.1]:59191 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPj2b-0005uJ-68 for submit@debbugs.gnu.org; Thu, 12 Jun 2025 10:36:29 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:54718) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPj2B-0005tE-TW for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 10:36:05 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=v84MzudPGB6a46G8Vz5KUZqS79WuJEGFNxC3+F7IcwY=; b=kDiZdiBMz42xl/Ksh5bElfMX09 rtoH7eDxZ6EtepNCGaBhRV0MT+bF4FrdYzQCJZNTXPQOoEL17Mc5MzrKHl8e+SQziSnptmwkM4afS gkk1w44Rr2B8Lc6rzqN9wKI1NFM6kHJCMaix/tMHZZalzjeDFtBdWvxhnxt8GCl3WApXu1GxIYKa2 SV+vVQWRAIYBsS3WtYyDB4paRNCcqXq8ugFH7kH/n7fx734jEF5V9GV/pBXwg/xXs8a0vwz75M0Mz /qH8zTNJ0VR3fOL5IJDSlp9Ch91fkf80Wz5alkuwM9YB++GbQ03IjGhdlLG/cAv7J20wCWlP4lNxr RHRnJuSQ==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPj0g-00BltU-1v; Thu, 12 Jun 2025 10:34:30 -0400 From: Daniel Colascione In-Reply-To: <87sek5ysbs.fsf@protonmail.com> References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Thu, 12 Jun 2025 07:35:51 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Pip Cet writes: > "Daniel Colascione" writes: > >> Eli Zaretskii writes: >> >>>> From: Daniel Colascione >>>> Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >>>> Date: Wed, 11 Jun 2025 07:08:45 -0700 >>>> >>>> Why is it good that read-key-sequence swallows quits but not read-char? >>> >>> I don't know. No one does. maybe there's a good reason for it, maybe >>> there was one at some point but there isn't anymore, maybe it's just a >>> historical accident. >>> >>> But being unable to answer such questions doesn't mean changing the >>> behavior is safe. It usually is the other way around, in a program as >>> old and complex as |Emacs. >>> >>>> C-g is an event. Why should read-event (but not read-key-sequence?) >>>> translate one kind of input event (C-g) to an action (signal quit) but >>>> return other kinds of events as they're given? >>> >>> You consider this to be an inconsistency based only on the name of the >>> API. But that's not necessarily the whole contract of the API. It >>> doesn't need to be called get-char-quit-when-c-g to behave like it >>> does. >>> >>> Anyway, I think arguing about this aspect is not useful. My problem >>> is not theoretical, it is practical: how much will break due to these >>> changes, and how long will it take us to become aware of the breakage >>> and attempt fixing it? >> >> I went through all the uses of read-char, read-char-exclusively, and >> read-event in the tree and didn't find anything that'll break if we make >> these functions return C-g as an event. I did some things that worked > > The first thing I looked at was mouse-drag-secondary. It breaks (not > too badly: it just loses a quit event, but it's still an undesirable > change in behavior). Recipe? mouse-drag-secondary seems to be working all right for me, but I never use the feature in anger so I might be missing something. >> marginally better, as I mentioned in my previous message. It's possible >> something breaks, but I haven't seen evidence of breakage yet. > > I'd say breaking (read-event) called in a loop is bad enough, because > how else are you supposed to start developing code which uses it? No worse than calling read-key-sequence. >> Yes, and for cases in which we're changing user-visible semantics in a >> way that'll break workflows --- like beginning-of-defun, perhaps --- >> then I agree with you. I don't think this particular change belongs to >> that category. I've looked for evidence that would change my mind and >> haven't found any yet. You're right that changes to the input loop are >> risky, but they're going to be necessary sooner or later anyway, so >> wouldn't you prefer to change simpler code? > > Since we've progressed to testing the branch, with the implication being > that we'll merge it soon, it may be too late to make alternative > suggestions. In case it's not, though: > > I think this discussion is concerned too much with what existing code > will break if we change quit not to quit, not enough with how much more > difficult it will be to develop code if we do, and not at all, so far, > with what the advantages of handling quit in Lisp (if Lisp decides to > handle it at all) are. Lisp can quit just fine. What are you talking about? > C-g isn't an input event in the same way that kicking someone in the > shin is not a dance move. I want it to kick Emacs in the shin, and > break out of bad Lisp code, in *more* situations than it does now. C-g is an event. The quit mechanism is a low-level mechanism for breaking out of Lisp code in response to this event. It makes no sense one key on the keyboard with longjmp when we use a value for the two keys next to it. When code says it wants an event, it should get an event. That we interpret this event to mean quit in other circumstances doesn't mean it's no longer an event. > That would simplify things, and give us a more powerful quit rather than > one subject to innocent mistakes in Lisp code that looks just fine. The > "C-g quits" rule would simply take precedence over all other input > handling rules, simplifying the contract if that's what you think of it > as. I don't believe it's easier if we handle all keyboard events except one by returning a value but longjmp on this one special one. > People who don't want quit to quit could then call (set-quit-char nil) > or something similar and reuse the quit character for something else. > Something like that should be the only way to disable this extremely > useful feature, though. Huh? Nobody's disabling quit. > We could even make it the default behavior and let people who want quit > put it in their init files. > > Independently of all this, we should change our triple C-g detection to > work in cases where a Lisp user or keyboard.c clears quit-flag without > actually handling the quit. If we change things so C-g is ordinary > input, we can at least limit the damage and let people use triple C-g in > the unquittable infloops that will result (triple C-g isn't safe and you > should restart your Emacs session after using it, but that's less > inconvenient than losing the entire session). Have you gotten your branches mixed up? You seem to be ranting about a set of patches with little resemblance to the ones we're discussing. The branch we're talking about doesn't stop C-g quitting Lisp. > Maybe a compromise would be to continue the arms race and downgrade C-g > to normal input, C-g C-g C-g to a quit, and require even more C-g's for > a force-quit? > >> Along the same lines, we could get rid of getcjmp too. I'm not afraid >> of rationalizing the contract of read-event or tweaking any other part >> of keyboard.c, but that thing and quit_throw_to_read_char are extremely >> confusing and do scare me a bit --- all the more reason, in my mind, to >> get rid of them, like Gerd wanted to do years ago. When is the right >> time to do that? It's not like an Emacs 31 release is imminent. > > I think that's a different discussion, to be honest. > > getcjmp should be changed, definitely: it's currently updated > non-atomically using memcpy, which means we might longjmp to an > inconsistent jmp_buf from a signal handler and crash, IIUC. We don't jump in signal handlers for input. If we did, we'd have much bigger problems. when's the last time you read keyboard.c? handle_input_available_signal doesn't jump anywhere. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 16:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174974471315458 (code B ref 78737); Thu, 12 Jun 2025 16:12:02 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 16:11:53 +0000 Received: from localhost ([127.0.0.1]:59657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPkWu-00041E-GY for submit@debbugs.gnu.org; Thu, 12 Jun 2025 12:11:53 -0400 Received: from mail-24417.protonmail.ch ([109.224.244.17]:15141) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPkWq-00040b-JH for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 12:11:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749744702; x=1750003902; bh=WwA1fZ/r7D0wW+LldxLiAhPhtKT5kB4GpJR2QTadi0o=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=iA3+TOa511aMKdS2dBg45vddxvyNHM0BzOtVtrypz48PNGzRss7VMhxYeFAxH1RH7 qXd8a88xUjXt+AYYqv+/nNCVUfCIDBWKmimseHIkqp5rlIPQWDMpfuT5U+gTwZFGm5 2RLduI7wp98cXVD7qH+XL/10vKqylJKUXgRj0l9EXuk3smuZ3/afynZFMxgBsN7/CY 0WP9xcsNPlRPpxF3N+HLmxaqVHkH3sMWUx9ClPjlI3OHZe7sbkWaz0ZcKt6qQENRLA nxRr4bwKA+7bPbzg++9KGRz6AWNHUXyE9W4SOe6CiiYLH5uRgfJc3U97yLzCeIWuGF AAoEIDw9Pdu/A== Date: Thu, 12 Jun 2025 16:11:35 +0000 From: Pip Cet Message-ID: <87ikl1ym6m.fsf@protonmail.com> In-Reply-To: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 7713a0c4db75fffb516cdfcdbd8373bd0e9039b6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) 1"Daniel Colascione" writes: > Pip Cet writes: > >> The first thing I looked at was mouse-drag-secondary. It breaks (not >> too badly: it just loses a quit event, but it's still an undesirable >> change in behavior). > > Recipe? mouse-drag-secondary seems to be working all right for me, but > I never use the feature in anger so I might be missing something. Start dragging. Quit. Result on your branch: drag ends, no quit happens Expected result: drag ends, quit happens (I'm not sure about the behavior change of event-apply-*-modifier. Maybe those functions should bind inhibit-quit around the read-event call so you can compose M-C-g as "C-x @ m C-g". However, binding M-C-g is still a bad idea, because someone might type "ESC C-g" for it and that would cause a quit when in Lisp code.) >>> marginally better, as I mentioned in my previous message. It's possibl= e >>> something breaks, but I haven't seen evidence of breakage yet. >> >> I'd say breaking (read-event) called in a loop is bad enough, because >> how else are you supposed to start developing code which uses it? > > No worse than calling read-key-sequence. Yes, worse than that, if only because read-event is usually called within a loop, while read-key-sequence isn't. I disagree with the implication that every piece of Emacs source code that is broken in some way justifies breaking other places in the same way. >> Since we've progressed to testing the branch, with the implication being >> that we'll merge it soon, it may be too late to make alternative >> suggestions. In case it's not, though: >> >> I think this discussion is concerned too much with what existing code >> will break if we change quit not to quit, not enough with how much more >> difficult it will be to develop code if we do, and not at all, so far, >> with what the advantages of handling quit in Lisp (if Lisp decides to >> handle it at all) are. > > Lisp can quit just fine. What are you talking about? With your patches, Lisp now has the responsibility to handle quits in many more situations, such as when it calls read-event. >> People who don't want quit to quit could then call (set-quit-char nil) >> or something similar and reuse the quit character for something else. >> Something like that should be the only way to disable this extremely >> useful feature, though. > > Huh? Nobody's disabling quit. You are, for some Lisp programs. (while t (read-event)) is Lisp code which should be quittable. On your branch, it's not quittable. Thus, you've disabled quit in this situation. >> Independently of all this, we should change our triple C-g detection to >> work in cases where a Lisp user or keyboard.c clears quit-flag without >> actually handling the quit. If we change things so C-g is ordinary >> input, we can at least limit the damage and let people use triple C-g in >> the unquittable infloops that will result (triple C-g isn't safe and you >> should restart your Emacs session after using it, but that's less >> inconvenient than losing the entire session). > > The branch we're talking about doesn't stop C-g quitting Lisp. You're making Lisp programs (which use C subroutines) unquittable when they weren't before. I did not say that means "stop C-g quitting Lisp". > Have you gotten your branches mixed up? You seem to be ranting about a > set of patches with little resemblance to the ones we're discussing. > when's the last time you read keyboard.c? What's the point of such personal attacks? It's totally inappropriate to suggest I did not read the source code, regardless of whether it's correct or not. And even if I misunderstood your patches, that tone is inappropriate. (It doesn't matter much, but I was correct in both of these cases: your patch disables quit in some (too many) situaitons, and we do longjmp from signal handlers in keyboard.c, as the code clearly states.) > We don't jump in signal handlers for input. If we did, we'd have much > bigger problems. Of course we do. #0 0x00007ffff5bba260 in __longjmp_chk () at /lib64/libc.so.6 #1 0x00005555555aa1b8 in quit_throw_to_read_char (from_signal=3Dfrom_signa= l@entry=3Dtrue) at keyboard.c:12425 #2 0x00005555555aa24f in handle_interrupt (in_signal_handler=3D) at keyboard.c:12400 #3 0x000055555570cfca in deliver_process_signal (sig=3D2, handler=3D0x5555= 556eab10 ) at sysdep.c:1751 #4 0x00007ffff5adaed0 in () at /lib64/libc.so.6 As for the rest of your email, you mention longjmp a few times. We don't disagree on that point: if we can handle quits without using longjmp (including longjmp from signal handlers), we should do that. I hope you'll understand I might take a break from this discussion. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 16:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174974596020820 (code B ref 78737); Thu, 12 Jun 2025 16:33:02 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 16:32:40 +0000 Received: from localhost ([127.0.0.1]:59749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPkr1-0005Pj-F1 for submit@debbugs.gnu.org; Thu, 12 Jun 2025 12:32:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37538) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPkqy-0005PN-5P for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 12:32:36 -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 1uPkqq-00088M-Pc; Thu, 12 Jun 2025 12:32:29 -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=7F6TVKIIrwVs1+uHyuM9BS8dTJIdaSen52+dEfhhQCg=; b=icTpKO13bG4u FHvHKjmr8uwHspSRdee67Jq66SaSKRfsUBRpVHNv9vjCK4IOTQlNjoIRgbqKW2l+PumulRa3LKVpI 8KgKVqCqMjh/RDalWtr6zpGxOfOtgcV/Oc0FntwlKSxpDaa7OICP6RCC+JksSY8n/P0E+Q8rACipV p2AD6TFo+E45oIBdYJ9hok5sVihVMdYkpl1pCK9SoOk/Tw/kOe5+v3V4m3UnWXAuQfDpIHgqYzdmz 57tCWf/YEIYwUpg6UlLs34kWUb56Y5oXMvd9otUDNAJ4OOC9Sfh75ZwkNANDoF2jrDmFWy0TKy0h5 HdTxpUuvA307/fcDjzZKsA==; Date: Thu, 12 Jun 2025 19:32:26 +0300 Message-Id: <86bjqsgbtx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87sek5ysbs.fsf@protonmail.com> (message from Pip Cet on Thu, 12 Jun 2025 13:58:51 +0000) References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> X-Spam-Score: -2.3 (--) 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: Thu, 12 Jun 2025 13:58:51 +0000 > From: Pip Cet > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > > I'd say breaking (read-event) called in a loop is bad enough, because > how else are you supposed to start developing code which uses it? Maybe this regression should be fixed, then. > Since we've progressed to testing the branch, with the implication being > that we'll merge it soon, it may be too late to make alternative > suggestions. We will merge only after we agree that (a) it does TRT, and (b) that it was tested sufficiently well and all the problems it might cause have been dealt with. So it isn't too late to argue that the branch does something incorrectly or sub-optimally. > I think this discussion is concerned too much with what existing code > will break if we change quit not to quit, not enough with how much more > difficult it will be to develop code if we do, and not at all, so far, > with what the advantages of handling quit in Lisp (if Lisp decides to > handle it at all) are. > > C-g isn't an input event in the same way that kicking someone in the > shin is not a dance move. I want it to kick Emacs in the shin, and > break out of bad Lisp code, in *more* situations than it does now. Please describe the situations where you'd like it to throw to top level and it doesn't now. Also, can this behavior be optional, like debug-on-error and friends are? Not everyone debugs Lisp code all the time, so we definitely can have an "easy-break-out" feature that is by default off. > Maybe a compromise would be to continue the arms race and downgrade C-g > to normal input, C-g C-g C-g to a quit, and require even more C-g's for > a force-quit? That's also possible, though less desirable: counting C-g presses when you are desperate is not easy and we cannot rely on users to do that reliably. > > Along the same lines, we could get rid of getcjmp too. I'm not afraid > > of rationalizing the contract of read-event or tweaking any other part > > of keyboard.c, but that thing and quit_throw_to_read_char are extremely > > confusing and do scare me a bit --- all the more reason, in my mind, to > > get rid of them, like Gerd wanted to do years ago. When is the right > > time to do that? It's not like an Emacs 31 release is imminent. > > I think that's a different discussion, to be honest. I agree, and I think so does Daniel. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 16:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174974661023620 (code B ref 78737); Thu, 12 Jun 2025 16:44:01 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 16:43:30 +0000 Received: from localhost ([127.0.0.1]:59826 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPl1V-00068u-Kc for submit@debbugs.gnu.org; Thu, 12 Jun 2025 12:43:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57468) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPl1T-00068X-1t for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 12:43: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 1uPl1L-0000oZ-8q; Thu, 12 Jun 2025 12:43:20 -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=nhuKXQb7jxj22Pgf2N78AC4/y83OUP0Os5/hGaRuWsI=; b=OJPRjdUYRH7r p0cl4R5q1/Me5/cajryXQz6LrIRC/PaUDYgdPn1DGAnHWiL5OS+XkcoBIVz0jq+XFfOAO5ZqyJt3s Z8MXmRDzCVQmt5BGMh2H5qeRQKh9XHem4/JVpQA5xSwnnKz3Q3eNghr48UxO5iz+1P0QbP9ck0my7 DHTgWOyosRegSfCCmvpATeqR8RGcsMQ8aOTb92DgA3HiURy6CkXy3vKEa8OtqxqFl3DVggzU+fPBc 9DvKF13GbwmCDcYJs4hnrWVjJnaGFC5IN5d7DxEkMDsop5DQyeDc7H+7GTbYTVMSFgsFBBnqQRw+5 SfkNHIAvL8zLK2JwcKp53g==; Date: Thu, 12 Jun 2025 19:43:12 +0300 Message-Id: <868qlwgbbz.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87ikl1ym6m.fsf@protonmail.com> (message from Pip Cet on Thu, 12 Jun 2025 16:11:35 +0000) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <87ikl1ym6m.fsf@protonmail.com> X-Spam-Score: -2.3 (--) 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: Thu, 12 Jun 2025 16:11:35 +0000 > From: Pip Cet > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > > > when's the last time you read keyboard.c? > > What's the point of such personal attacks? It's totally inappropriate > to suggest I did not read the source code, regardless of whether it's > correct or not. And even if I misunderstood your patches, that tone is > inappropriate. > > (It doesn't matter much, but I was correct in both of these cases: your > patch disables quit in some (too many) situaitons, and we do longjmp > from signal handlers in keyboard.c, as the code clearly states.) > > > We don't jump in signal handlers for input. If we did, we'd have much > > bigger problems. > > Of course we do. You are both right: on TTY's C-g triggers SIGINT, and we do longjmp from the SIGINT handler; on X C-g (like any keypress) triggers SIGIO, and we do NOT longjmp from the SIGIO handler. Anyway, can we please cool down and discuss this in a more friendly fashion? Daniel, if Pip has some reservations about the design or the implementation on the branch, please make the effort to explain your ideas and goals, and please try to address the concerns. We should strive to arrive at changes on which we all agree, and we should be on the same page regarding the goals and the means to reach those goals. > I hope you'll understand I might take a break from this discussion. I hope no one takes a break because they feel attacked. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 16:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Pip Cet Cc: 78737@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174974715626242 (code B ref 78737); Thu, 12 Jun 2025 16:53:01 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 16:52:36 +0000 Received: from localhost ([127.0.0.1]:59882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPlAJ-0006pB-E8 for submit@debbugs.gnu.org; Thu, 12 Jun 2025 12:52:35 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:36022) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPlAG-0006oo-BW for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 12:52:33 -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=67GxSJWWMLTjNyIFmjIzPfoKJovvAL4CryVK2vdcAnU=; b=lLNZozWsy5dmvMk/v5NjgXtnxC y9mzavNmKbS+f8LZaKHw0X/lP/GVCsJM3kms0g/tnUMaD5WMQXUKi6Oh4cvAJpLUkWUJ3DrZ63Gmb gLX9s4mmChKJbsdBBk0l/wXs+jVQE9v8QFmKm/uIPwal9yr73KAHJucwpTCxheZIhxHglXajmUm77 Ei5CaFoCHmfPLTIBK9JqCdHg2VzgIeMhKAN/3cUN4AHU+LNpSx2x9cyA5QZ9nZdGYJZs/eknRcNWa wjkn+kgBOQ6ecGPReowyGEZIz7W+L/7m7AtwI/o/EVJ/03Jsac6yqZMwTOSrAybdAy74JkDmK2zQX FaraaCdQ==; Received: from [2600:1010:b047:2f06:0:48:6379:f01] (port=39186 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 1uPl8p-00BnFA-00; Thu, 12 Jun 2025 12:51:03 -0400 Date: Thu, 12 Jun 2025 09:52:22 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <86bjqsgbtx.fsf@gnu.org> References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.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-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 June 12, 2025 9:32:26 AM PDT, Eli Zaretskii wrote: >> Date: Thu, 12 Jun 2025 13:58:51 +0000 >> From: Pip Cet >> Cc: Eli Zaretskii , monnier@iro=2Eumontreal=2Eca, 78737= @debbugs=2Egnu=2Eorg >>=20 >> I'd say breaking (read-event) called in a loop is bad enough, because >> how else are you supposed to start developing code which uses it? > >Maybe this regression should be fixed, then=2E It's not a regression=2E It's a bug fix=2E Not every behavior change is a = problem=2E Who starts coding something by calling it in a loop? That's like= learning to drive by crashing into a wall=2E And besides, like I keep saying, read-key-sequence works the same way read= -event does and over lots of decades nobody to my knowledge has called it u= nprogrammable=2E You have to think about these things, not just reflexively conclude that i= t's bad because it's different=2E >> Since we've progressed to testing the branch, with the implication bein= g >> that we'll merge it soon, it may be too late to make alternative >> suggestions=2E > >We will merge only after we agree that (a) it does TRT, and (b) that >it was tested sufficiently well and all the problems it might cause >have been dealt with=2E > >So it isn't too late to argue that the branch does something >incorrectly or sub-optimally=2E > >> I think this discussion is concerned too much with what existing code >> will break if we change quit not to quit, not enough with how much more >> difficult it will be to develop code if we do, and not at all, so far, >> with what the advantages of handling quit in Lisp (if Lisp decides to >> handle it at all) are=2E >>=20 >> C-g isn't an input event in the same way that kicking someone in the >> shin is not a dance move=2E I want it to kick Emacs in the shin, and >> break out of bad Lisp code, in *more* situations than it does now=2E > >Please describe the situations where you'd like it to throw to top >level and it doesn't now=2E Also, can this behavior be optional, like >debug-on-error and friends are? Not everyone debugs Lisp code all the >time, so we definitely can have an "easy-break-out" feature that is by >default off=2E > >> Maybe a compromise would be to continue the arms race and downgrade C-g >> to normal input, C-g C-g C-g to a quit, and require even more C-g's for >> a force-quit? Yes, that's what I have in mind, and it'll help in other situations in whi= ch we eat C-g today=2E Don't think of it as upgrading a quit, but rather hi= nting to Emacs that it should interpret C-g as quit in situations it would = otherwise interpret it as an event=2E Not every C-g is a quit=2E The branch creates a simple mental model of how this works: 1=2E By default, C-g is an input event like everything else=2E You can rea= d it, read a key sequence involving it, and bind it to keymaps like any oth= er key=2E 2=2E As a special feature, Emacs interprets C-g while Lisp is running (not= blocked on input) to mean that it should raise a special signal, called qu= it, and take you back to the command loop ASAP=2E 3=2E Lisp code can disable #2 in a section of code by binding inhibit-quit= around anything that's important to run without interruption=2E 4=2E If you hit C-g enough times in a short enough time, we treat C-g as a= quit even in contexts where we're trying to read input=2E We display a mes= sage when doing so=2E For example, at this stage, we can break out of (whil= e t (read-char))=2E 5=2E If you continue to hit C-g, we conclude Emacs is hooked and disable i= nhibit-quit so you can break out of sections of code marked ordinarily unbr= eakable=2E Doing so may break your Emacs, so we'll display a message saying= this has happened=2E #4 and #5 aren't implemented on the branch, but will be=2E We do have a le= gacy force quit feature, but it skips #4 and goes straight to #5, and it ne= ver worked for me in GUI Emacs anyway=2E >That's also possible, though less desirable: counting C-g presses when >you are desperate is not easy and we cannot rely on users to do that >reliably=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 16:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174974739827345 (code B ref 78737); Thu, 12 Jun 2025 16:57:01 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 16:56:38 +0000 Received: from localhost ([127.0.0.1]:59904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPlEE-00076z-0g for submit@debbugs.gnu.org; Thu, 12 Jun 2025 12:56:38 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39812) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPlEA-00076Y-Jq for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 12:56:35 -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 1uPlE5-0002s4-7T; Thu, 12 Jun 2025 12:56:29 -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=WaRyDSPKqpQtV0XFC1/+QeS6qb73gAHp7AxRGvt8S1Q=; b=Hp+0pt+2xIK/ kJr5kGyRvipzq7bXKsnl+HQrrYCfomQIklx+NMNUpblWn5QeU5GpO4U7ena08PFfAOQs2o0MdYH7I 9jwmrQVWU19MkwVFGuCnxJgPz8MW5049IJhkJ3/iavsOzqiTwq97ElLF2Ay9xA72mGEgtouGytOeb ogir/qEunQEuWkfs4z9IAxSlLP2br8+ZkzUHn8d9UABCqxNl4tL4aYGVEatqxYg9ESR6exCs46yXD Ob7NbeyTScRC0gDCa9GWxuBdqkEbz/u0bhIdNqgsFsQTW1EwdP9sRnVRyOUotj5xVyFciqoIPTf8B +se56pXQCNhIiILT0WkYRw==; Date: Thu, 12 Jun 2025 19:56:26 +0300 Message-Id: <865xh0gapx.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Thu, 12 Jun 2025 09:52:22 -0700) References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Thu, 12 Jun 2025 09:52:22 -0700 > From: Daniel Colascione > CC: monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > > > > On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii wrote: > >> Date: Thu, 12 Jun 2025 13:58:51 +0000 > >> From: Pip Cet > >> Cc: Eli Zaretskii , monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > >> > >> I'd say breaking (read-event) called in a loop is bad enough, because > >> how else are you supposed to start developing code which uses it? > > > >Maybe this regression should be fixed, then. > > It's not a regression. It's a bug fix. Not every behavior change is a problem. Who starts coding something by calling it in a loop? That's like learning to drive by crashing into a wall. Did it never happen to you that you wrote a loop and forgot the part that advances the counter or some other thing that will prevent an infloop? Stuff happens when developing code. > You have to think about these things, not just reflexively conclude that it's bad because it's different. Daniel, you are not the only one who thinks about this. The fact that people disagree doesn't necessarily mean they didn't think. Let's try to leave such "arguments" out of the discussion. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 17:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17497504308152 (code B ref 78737); Thu, 12 Jun 2025 17:48:01 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 17:47:10 +0000 Received: from localhost ([127.0.0.1]:60127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPm17-00027Q-Qj for submit@debbugs.gnu.org; Thu, 12 Jun 2025 13:47:10 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:45178) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPm14-000277-SG for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 13:47:07 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=iWUnTNY+01IO9f49zzO4nSp/RT06Zs7jrfflrrU7wbQ=; b=mPKBSq+tuzoQ11wLvZdE0CgXA0 S1Zz1bBVL9dpzKiguul74afMyeQUS7Zb3aSBunWL2mnvmg67bK7GJMssyTCopPzMjTdmKQmkT1N2w FZrdGfgmgCSiq8wivmdFbg3NkyU12kfpWOlqi8hIJsnbiHIL3gNQ0ZJyihskKuzYAlVyn3V4cRKuH N2RKt/HQEmMpxK15BaW6WJE8DXQdU8oLk/LvrxIVoLUTCdqX1goIkc8oR6zXr8RyNNAhAA0X3it7+ 34XCNLIlhXkEuLDVJk0DLiG5pv1bRZdDQHpwEgZj0ryZijwpzWy/v/dRkbs1QYBIYCGfRN/mcb2mB GXlJd6sA==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPlzb-00BoHZ-0y; Thu, 12 Jun 2025 13:45:35 -0400 From: Daniel Colascione In-Reply-To: <87ikl1ym6m.fsf@protonmail.com> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <87ikl1ym6m.fsf@protonmail.com> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Thu, 12 Jun 2025 10:46:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Pip Cet writes: > 1"Daniel Colascione" writes: > >> Pip Cet writes: >> >>> The first thing I looked at was mouse-drag-secondary. It breaks (not >>> too badly: it just loses a quit event, but it's still an undesirable >>> change in behavior). >> >> Recipe? mouse-drag-secondary seems to be working all right for me, but >> I never use the feature in anger so I might be missing something. > > Start dragging. Quit. > > Result on your branch: drag ends, no quit happens > Expected result: drag ends, quit happens I'd classify that as code working better. No user scenario has "broken". If we want to display a message that the drag has ended, let's display a message saying that in particular. > (I'm not sure about the behavior change of event-apply-*-modifier. Maybe > those functions should bind inhibit-quit around the read-event call so > you can compose M-C-g as "C-x @ m C-g". However, binding M-C-g is still > a bad idea, because someone might type "ESC C-g" for it and that would > cause a quit when in Lisp code.) Users can do plenty of things that are bad ideas. >>>> marginally better, as I mentioned in my previous message. It's possible >>>> something breaks, but I haven't seen evidence of breakage yet. >>> >>> I'd say breaking (read-event) called in a loop is bad enough, because >>> how else are you supposed to start developing code which uses it? >> >> No worse than calling read-key-sequence. > > Yes, worse than that, if only because read-event is usually called > within a loop, while read-key-sequence isn't. If it were a problem, we'd have seen more things break. What user scenario is broken? > I disagree with the implication that every piece of Emacs source code > that is broken in some way justifies breaking other places in the same > way. It's not broken. >>> Since we've progressed to testing the branch, with the implication being >>> that we'll merge it soon, it may be too late to make alternative >>> suggestions. In case it's not, though: >>> >>> I think this discussion is concerned too much with what existing code >>> will break if we change quit not to quit, not enough with how much more >>> difficult it will be to develop code if we do, and not at all, so far, >>> with what the advantages of handling quit in Lisp (if Lisp decides to >>> handle it at all) are. >> >> Lisp can quit just fine. What are you talking about? > > With your patches, Lisp now has the responsibility to handle quits in > many more situations, such as when it calls read-event. No, read-event _reads an event_. It's not the job of read-event to also quit. Quitting is for breaking out of running code. It's not a side channel for general input. >>> People who don't want quit to quit could then call (set-quit-char nil) >>> or something similar and reuse the quit character for something else. >>> Something like that should be the only way to disable this extremely >>> useful feature, though. >> >> Huh? Nobody's disabling quit. > > You are, for some Lisp programs. > > (while t > (read-event)) > > is Lisp code which should be quittable. On your branch, it's not > quittable. Thus, you've disabled quit in this situation. This is a "doctor, it hurts when I do this" situation. If we had a bug causing (/ 8 2) to report 3 instead of 4, you could argue that we regressed a function calling (and (= (/ 8 2) 3) (insert "blah")). >>> Independently of all this, we should change our triple C-g detection to >>> work in cases where a Lisp user or keyboard.c clears quit-flag without >>> actually handling the quit. If we change things so C-g is ordinary >>> input, we can at least limit the damage and let people use triple C-g in >>> the unquittable infloops that will result (triple C-g isn't safe and you >>> should restart your Emacs session after using it, but that's less >>> inconvenient than losing the entire session). >> >> The branch we're talking about doesn't stop C-g quitting Lisp. > > You're making Lisp programs (which use C subroutines) unquittable when > they weren't before. I did not say that means "stop C-g quitting > Lisp". You constructed an unrealistic program. People do call (read-event) in a loop, but they _do something_ with the event. Otherwise, why would they call it and not (sit-for) or something? >> Have you gotten your branches mixed up? You seem to be ranting about a >> set of patches with little resemblance to the ones we're discussing. > >> when's the last time you read keyboard.c? > > What's the point of such personal attacks? It's totally inappropriate > to suggest I did not read the source code, regardless of whether it's > correct or not. And even if I misunderstood your patches, that tone is > inappropriate. > > (It doesn't matter much, but I was correct in both of these cases: your > patch disables quit in some (too many) situaitons, and we do longjmp > from signal handlers in keyboard.c, as the code clearly states.) > >> We don't jump in signal handlers for input. If we did, we'd have much >> bigger problems. > > Of course we do. > > #0 0x00007ffff5bba260 in __longjmp_chk () at /lib64/libc.so.6 > #1 0x00005555555aa1b8 in quit_throw_to_read_char (from_signal=from_signal@entry=true) at keyboard.c:12425 > #2 0x00005555555aa24f in handle_interrupt (in_signal_handler=) at keyboard.c:12400 > #3 0x000055555570cfca in deliver_process_signal (sig=2, handler=0x5555556eab10 ) at sysdep.c:1751 > #4 0x00007ffff5adaed0 in () at > /lib64/libc.so.6 In my testing, on macOS (even without a window system), I see this happen _only_ inside pselect, which doesn't really count: that's a singular known point, not arbitrary code. That's correct, if ugly. In this part of the code, there's no chance of a write to getcjmp being torn: the system call functions as a memory barrier. If we can jump through _arbitrary code_ on other platforms, that's a big problem, since if I'm reading this right, we can call arbitrary Lisp via Fdo_auto_save. That would be dangerous and would always have been. But even if we _could_ call through arbitrary code this way, we still wouldn't tear getcjmp because we call pthread_sigmask (SIG_SETMASK, &empty_mask, 0) after we set it, and the system call acts as a memory barrier again. (We don't handle this signal on non-main threads either if I'm reading this right.) But who knows? This code is tangled and the safer thing would be to get rid of signal handlers that do more than set flags. > As for the rest of your email, you mention longjmp a few times. We > don't disagree on that point: if we can handle quits without using > longjmp (including longjmp from signal handlers), we should do that. We should just treat TTY quits like GUI quits and quits from secondary TTYs. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 18:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174975146212568 (code B ref 78737); Thu, 12 Jun 2025 18:05:02 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 18:04:22 +0000 Received: from localhost ([127.0.0.1]:60208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPmHl-0003Ge-NQ for submit@debbugs.gnu.org; Thu, 12 Jun 2025 14:04:22 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:47434) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPmHi-0003GJ-4X for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 14:04:19 -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=zUX1/hNjG6dhTo/U0nY+LzPKZUCGFaLlQfXoMI7FYBc=; b=fd0ynujYsivYTW3z4dFfdUiMH1 p0aFIljCeMrdIyB24JbMGQyYaujjIFb9Enss9Lg2Ol5V3Wu/AiwJGWstmp0cRwZQrdmusSf0lQRk2 LQi7u1cRmVWFa0sN6mm9SeiF9m1TbCKxan3vpAo8zvHMv8Qx0jGGD3lsnieSlyy2px3CbSJkxj56U wN2sfW85QBPTKQTbsLm9/ErPbThzAbO1Qi6UGpRBkSHQ0RlIhRgDPfx2bMzYW4J/bWvUr/iGbsIdt 0reay27DSB2r52XHeIW4xZljb3JOcl3eRUrQiKWgB4VTguIpbwgkVQNBDZ8j+iQToM025aZo5ePmV 1GF6NSPg==; Received: from [2600:1010:b047:2f06:0:48:6379:f01] (port=59948 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 1uPmGF-00BoRf-0v; Thu, 12 Jun 2025 14:02:47 -0400 Date: Thu, 12 Jun 2025 11:04:06 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <865xh0gapx.fsf@gnu.org> References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> Message-ID: <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 12, 2025 9:56:26 AM PDT, Eli Zaretskii wrote: >> Date: Thu, 12 Jun 2025 09:52:22 -0700 >> From: Daniel Colascione >> CC: monnier@iro=2Eumontreal=2Eca, 78737@debbugs=2Egnu=2Eorg >>=20 >>=20 >>=20 >> On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii wrote: >> >> Date: Thu, 12 Jun 2025 13:58:51 +0000 >> >> From: Pip Cet >> >> Cc: Eli Zaretskii , monnier@iro=2Eumontreal=2Eca, 78= 737@debbugs=2Egnu=2Eorg >> >>=20 >> >> I'd say breaking (read-event) called in a loop is bad enough, becaus= e >> >> how else are you supposed to start developing code which uses it? >> > >> >Maybe this regression should be fixed, then=2E >>=20 >> It's not a regression=2E It's a bug fix=2E Not every behavior change is= a problem=2E Who starts coding something by calling it in a loop? That's l= ike learning to drive by crashing into a wall=2E > >Did it never happen to you that you wrote a loop and forgot the part >that advances the counter or some other thing that will prevent an >infloop? Stuff happens when developing code=2E And the mechanism I described just now addresses the problem of recovering= from programmer error=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 18:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174975328920416 (code B ref 78737); Thu, 12 Jun 2025 18:35:02 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 18:34:49 +0000 Received: from localhost ([127.0.0.1]:60345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPmlE-0005JD-Pp for submit@debbugs.gnu.org; Thu, 12 Jun 2025 14:34:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54452) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPmlB-0005Ip-Rk for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 14:34:46 -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 1uPml5-0007F4-0d; Thu, 12 Jun 2025 14:34:39 -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=U2JExznqseN1j7gKlt/ApC9G/RIHpYoI8gjCHConB6E=; b=hmQ9VvBrCsP8 XXHzZRdRy5EecDa/FkJ5dv9aP/ithg0Ejtn6/pL6PCcok40daNZrAyNsTp88/IjC08KmRvvxcdUAV nyiYNuIWVYqZluzlRY2NjmIaVh/UJWaJqgceM7mP9oW2M3y1DUCb2vnVS3aHJTGNUYoARNVrvfBny AuOotAu5Boz1BZIQcoSI7eOPEs/2OAKxeO71lWygynyDdju2zGQ8Loug/zvXCOe+q3tNT9QogxXD9 qMqENPQYxXC7dorKVCKeKdejd6yDnU44oh2dg1Uh2DInEiBO1fNxXMSZD8frjc5tQ0Ein+8JKuoy1 Ubr7NKr4NsWPOWlRQmllNg==; Date: Thu, 12 Jun 2025 21:34:31 +0300 Message-Id: <86y0twerm0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> (message from Daniel Colascione on Thu, 12 Jun 2025 11:04:06 -0700) References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> X-Spam-Score: -2.3 (--) 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: Thu, 12 Jun 2025 11:04:06 -0700 > From: Daniel Colascione > CC: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > > > > On June 12, 2025 9:56:26 AM PDT, Eli Zaretskii wrote: > >> Date: Thu, 12 Jun 2025 09:52:22 -0700 > >> From: Daniel Colascione > >> CC: monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > >> > >> > >> > >> On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii wrote: > >> >> Date: Thu, 12 Jun 2025 13:58:51 +0000 > >> >> From: Pip Cet > >> >> Cc: Eli Zaretskii , monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > >> >> > >> >> I'd say breaking (read-event) called in a loop is bad enough, because > >> >> how else are you supposed to start developing code which uses it? > >> > > >> >Maybe this regression should be fixed, then. > >> > >> It's not a regression. It's a bug fix. Not every behavior change is a problem. Who starts coding something by calling it in a loop? That's like learning to drive by crashing into a wall. > > > >Did it never happen to you that you wrote a loop and forgot the part > >that advances the counter or some other thing that will prevent an > >infloop? Stuff happens when developing code. > > And the mechanism I described just now addresses the problem of recovering from programmer error. Sorry, I must have missed it (assuming that was in your previous message). Could you please point me to that description, or repeat it? Specifically, what I'm interested in is how come (while t (read-event)) cannot be interrupted by C-g, but you seem to be saying that (while t (let (evt (read-event)) (do-something-with evt))) _can_ be interrupted? Let's say when I type C-g, the loop is stuck inside read-event: could you then describe how this latter loop could be interrupted in that case? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 18:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174975349421429 (code B ref 78737); Thu, 12 Jun 2025 18:39:02 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 18:38:14 +0000 Received: from localhost ([127.0.0.1]:60362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPmoX-0005ZY-Mn for submit@debbugs.gnu.org; Thu, 12 Jun 2025 14:38:14 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:57317) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPmoV-0005Ys-Ux for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 14:38:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749753483; x=1750012683; bh=CWDfs/T9OA+7VJoBN+dQ+YLx+5JekD6WV2gGQHrTdFg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=BFs2rf8I7sSLyTl29fl+NtLYDwyjnq10YeueaVs5C2nj9zLZ97qWeP8QkP7k2VpRn x5XnBzJruABeM/GXkwFHSboQECfUk4Rhi6MyZE7GTlpLd4L0w4dYk69YqX8DWFE99N YGKzzqbXRaGirDufs76UHNMHYiAbjtvFjJItn5qDW+MgCJMdaX9r4IPz/OA8PjzaOW 4oYG0LASITVzjwaHQUgHI+fMZjnN3g6mzxCs+j2M6ZtKX9YDaXkaPKx0KwJqTKQBwT HiLa+vB9JJ0f0uthSDtWDeuJIRwvU//oT1PB02RmvKZGQBpYordNEct7nqhI8NJA5o iJaGuW/43SgJw== Date: Thu, 12 Jun 2025 18:37:58 +0000 From: Pip Cet Message-ID: <875xh0ztz2.fsf@protonmail.com> In-Reply-To: <86bjqsgbtx.fsf@gnu.org> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 4c364e43e155e422771b1b1b6d7f2e1d6ca9acd9 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Eli Zaretskii" writes: >> Date: Thu, 12 Jun 2025 13:58:51 +0000 >> From: Pip Cet >> Cc: Eli Zaretskii , monnier@iro.umontreal.ca, 78737@debbug= s.gnu.org >> >> I'd say breaking (read-event) called in a loop is bad enough, because >> how else are you supposed to start developing code which uses it? > > Maybe this regression should be fixed, then. I agree it should be, if we can agree it is a regression; the other issues I see are SIGUSR2 handling (which seems fixable) and the question of whether saving unhandled events in unread-command-events is always the right choice. >> I think this discussion is concerned too much with what existing code >> will break if we change quit not to quit, not enough with how much more >> difficult it will be to develop code if we do, and not at all, so far, >> with what the advantages of handling quit in Lisp (if Lisp decides to >> handle it at all) are. >> >> C-g isn't an input event in the same way that kicking someone in the >> shin is not a dance move. I want it to kick Emacs in the shin, and >> break out of bad Lisp code, in *more* situations than it does now. > > Please describe the situations where you'd like it to throw to top > level and it doesn't now. One situation for ordinary quits; three for force-quit. Situation 1: I'd like read-event, when called while inhibit-quit is t, to report quits by setting quit-flag in addition to returning quit_char: it'll simplify the C code, and it would make (while t (let ((inhibit-quit t)) (read-event))) quittable, as I naively expected it to be. The old behavior would remain available, but require an extra let binding. Note that this isn't (let ((inhibit-quit t)) (while t (read-event))) While I'd like to change the C code to make this second case force-quittable, I see no way to perform an ordinary quit for this code. The reason I mention it is that removing /* If we report the quit char as an event, =09 don't do so more than once. */ if (!NILP (Vinhibit_quit)) =09Vquit_flag =3D Qnil; changes behavior for both loops: the first becomes quittable, the second becomes force-quittable. Situation 2: (while t (read-key-sequence "")) It'd be nice for this situation to be force-quittable; I don't see why it shouldn't be, even though what I implemented is a bit of a hack... Situation 3: Several force-quits in the same session. Reset force_quit_count to 0 once it reaches 3. I've seen force_quit_count reach higher values than 3 (there was no regular quit in between force quit attempts). > Also, can this behavior be optional, like debug-on-error and friends > are? Not everyone debugs Lisp code all the time, so we definitely can > have an "easy-break-out" feature that is by default off. Absolutely. We could easily make it customizable whether read-event sets quit-flag after a quit: 1. never 2. only when !inhibit-quit 3. always >> Maybe a compromise would be to continue the arms race and downgrade C-g >> to normal input, C-g C-g C-g to a quit, and require even more C-g's for >> a force-quit? > > That's also possible, though less desirable: counting C-g presses when > you are desperate is not easy and we cannot rely on users to do that > reliably. And we'd need a way to detect when a quit is handled (however we define "handled") so we could reset force_quit_counter. Not a trivial change. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 18:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, Eli Zaretskii , monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174975414124067 (code B ref 78737); Thu, 12 Jun 2025 18:50:01 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 18:49:01 +0000 Received: from localhost ([127.0.0.1]:60393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPmyy-0006G0-Nh for submit@debbugs.gnu.org; Thu, 12 Jun 2025 14:49:01 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:42434) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPmyw-0006Fb-8n for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 14:48:59 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=qj+FqXs48RzD74jEMgRJ+tOaOnl8z0lwwl3zDfu+s5Q=; b=Pd8TcRvB+qVPa/JH0XpnGLu4rW qPj/m2O0azIX25eM7apfgvUQwtjyelmIqguTmHnjT3DTJxUhSG3ZgwkPH6JbDFvjfmbFWTBLSwJpn Ncp/rvOl+TX6tV6jeoMZSoyugmb8ALoGoXHDsHcoA0XlTTdI+T8pKiH5gRZRoCeAndRmINV0zR+xp 8zLF5uvPOE6ZIdcfj8FWR9YlzaQtt29+WG6lZlrMxyS0uc9e/nSyQV61W8Lb0fTiO9jUHjhzHG0rv bNVjPQYhMeSXRuKYfptaAA1HRDKUgG/rTosy8MzH5Hw1DYezTf+E0gJUYqnaAkirGssPnbJXZ1st2 9am1WiHw==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPmxV-00Bosn-1S; Thu, 12 Jun 2025 14:47:29 -0400 From: Daniel Colascione In-Reply-To: <875xh0ztz2.fsf@protonmail.com> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Thu, 12 Jun 2025 11:48:50 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Pip Cet writes: > "Eli Zaretskii" writes: > >>> Date: Thu, 12 Jun 2025 13:58:51 +0000 >>> From: Pip Cet >>> Cc: Eli Zaretskii , monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >>> >>> I'd say breaking (read-event) called in a loop is bad enough, because >>> how else are you supposed to start developing code which uses it? >> >> Maybe this regression should be fixed, then. > > I agree it should be, if we can agree it is a regression; the other > issues I see are SIGUSR2 handling (which seems fixable) and the question > of whether saving unhandled events in unread-command-events is always > the right choice. > >>> I think this discussion is concerned too much with what existing code >>> will break if we change quit not to quit, not enough with how much more >>> difficult it will be to develop code if we do, and not at all, so far, >>> with what the advantages of handling quit in Lisp (if Lisp decides to >>> handle it at all) are. >>> >>> C-g isn't an input event in the same way that kicking someone in the >>> shin is not a dance move. I want it to kick Emacs in the shin, and >>> break out of bad Lisp code, in *more* situations than it does now. >> >> Please describe the situations where you'd like it to throw to top >> level and it doesn't now. > > One situation for ordinary quits; three for force-quit. > > Situation 1: > > I'd like read-event, when called while inhibit-quit is t, to report > quits by setting quit-flag in addition to returning quit_char: it'll > simplify the C code, and it would make > > (while t > (let ((inhibit-quit t)) > (read-event))) I strongly disagree. read-event should read an event. Setting quit-flag by side effect when it happens to read one key and not others makes the interface less regular and understandable. read-key-sequence is the high-level function. read-event is the low-level function. It makes zero sense for the high-level function to report a key event as a low-level event and for the low-level function to do special non-local flow control in response to that event. > quittable, as I naively expected it to be. The naive expectation is that this function do its job. > The old behavior would > remain available, but require an extra let binding. > > Note that this isn't > > (let ((inhibit-quit t)) > (while t > (read-event))) Then fix read-key-sequence, which acts the same way. > While I'd like to change the C code to make this second case > force-quittable, I see no way to perform an ordinary quit for this code. > The reason I mention it is that removing > > /* If we report the quit char as an event, > don't do so more than once. */ > if (!NILP (Vinhibit_quit)) > Vquit_flag = Qnil; > > changes behavior for both loops: the first becomes quittable, the second > becomes force-quittable. There is no reason for these loops to behave differently. If we want to make both force-quittable, as I described in https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-06/msg00629.html, but an ordinary press of C-g should not cause a quit when Lisp has explicitly asked to read an event by calling a function whose job it is to read events. > Situation 2: > > (while t > (read-key-sequence "")) > > It'd be nice for this situation to be force-quittable; I don't see why > it shouldn't be, even though what I implemented is a bit of a hack... > > Situation 3: > > Several force-quits in the same session. Reset force_quit_count to 0 > once it reaches 3. I've seen force_quit_count reach higher values than > 3 (there was no regular quit in between force quit attempts). Get rid of force_quit_count entirely and just detect (by writing into a ring buffer) whether we've received N quits in the last T milliseconds. That'll work the same way regardless of how quits gets detected. We can change N and T freely. On your Emacs, you can set N to one and T to zero. >> Also, can this behavior be optional, like debug-on-error and friends >> are? Not everyone debugs Lisp code all the time, so we definitely can >> have an "easy-break-out" feature that is by default off. > Absolutely. We could easily make it customizable whether read-event > sets quit-flag after a quit: > > 1. never > 2. only when !inhibit-quit > 3. always We can customize thresholds for general behavior, but I don't think we should not have preferences that alter the operation of fundamental Emacs primitives. You couldn't add a preference that made if regard 0 as well as nil as false, would you? >>> Maybe a compromise would be to continue the arms race and downgrade C-g >>> to normal input, C-g C-g C-g to a quit, and require even more C-g's for >>> a force-quit? >> >> That's also possible, though less desirable: counting C-g presses when >> you are desperate is not easy and we cannot rely on users to do that >> reliably. > > And we'd need a way to detect when a quit is handled (however we define > "handled") so we could reset force_quit_counter. Not a trivial change. You don't. You just upgrade any quit that happens under the N and T threshold above. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Jun 2025 19:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174975526629019 (code B ref 78737); Thu, 12 Jun 2025 19:08:02 +0000 Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 19:07:46 +0000 Received: from localhost ([127.0.0.1]:60516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPnH7-0007Xw-62 for submit@debbugs.gnu.org; Thu, 12 Jun 2025 15:07:45 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:56452) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPnH3-0007Xi-4x for 78737@debbugs.gnu.org; Thu, 12 Jun 2025 15:07:43 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=XYySaOvTvTl4UF/G2GFgCb9yEYD7putSH0QDFtbpBps=; b=cAgXxwwurxMj6vaMgb1r61BK6e FMORV+fI0zc+vej/unXJEsF52R1tIKbofnI1lDIj0iOHP8R+vj3eAsmn3bCDYawRjXS8M1y5u211a V2c5dQUhnGB4DbUolbTDJ+qF9tm7J5aKOzIT3WYTrL9Ot3zJszNH3wFyWOkRWnAOe964YwbD5w66a u5loj1OzZzejvOHg8BhWaeCI7xBPPviV8AHE/QtdOK7rslKzplPdtBZ0bG1j7JtHosXVXbqUVANox MJxIqqalxaoVm4tO3bg/PYFa8DUbaVz6sONa2FycP6vXo7q1PH+8mZk91zy7JaJh9Dfk6TDFyNtiy uczgPgVA==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPnFb-00Bp6t-1e; Thu, 12 Jun 2025 15:06:11 -0400 From: Daniel Colascione In-Reply-To: <86y0twerm0.fsf@gnu.org> References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> <86y0twerm0.fsf@gnu.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Thu, 12 Jun 2025 12:07:32 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Eli Zaretskii writes: >> Date: Thu, 12 Jun 2025 11:04:06 -0700 >> From: Daniel Colascione >> CC: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >> >> >> >> On June 12, 2025 9:56:26 AM PDT, Eli Zaretskii wrote: >> >> Date: Thu, 12 Jun 2025 09:52:22 -0700 >> >> From: Daniel Colascione >> >> CC: monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >> >> >> >> >> >> >> >> On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii wrote: >> >> >> Date: Thu, 12 Jun 2025 13:58:51 +0000 >> >> >> From: Pip Cet >> >> >> Cc: Eli Zaretskii , monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >> >> >> >> >> >> I'd say breaking (read-event) called in a loop is bad enough, because >> >> >> how else are you supposed to start developing code which uses it? >> >> > >> >> >Maybe this regression should be fixed, then. >> >> >> >> It's not a regression. It's a bug fix. Not every behavior change is a problem. Who starts coding something by calling it in a loop? That's like learning to drive by crashing into a wall. >> > >> >Did it never happen to you that you wrote a loop and forgot the part >> >that advances the counter or some other thing that will prevent an >> >infloop? Stuff happens when developing code. >> >> And the mechanism I described just now addresses the problem of recovering from programmer error. > > Sorry, I must have missed it (assuming that was in your previous > message). Could you please point me to that description, or repeat > it? It's near the bottom of https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-06/msg00629.html > Specifically, what I'm interested in is how come > > (while t > (read-event)) > > cannot be interrupted by C-g, but you seem to be saying that > > (while t > (let (evt (read-event)) > (do-something-with evt))) > > _can_ be interrupted? (read-event) returns \?C-g. If the C-g arrives when Lisp code is running (e.g. inside (do-something-with evt), then we quit --- unless that code is also reading an event, in which case we return it. > Let's say when I type C-g, the loop is stuck > inside read-event: could you then describe how this latter loop could > be interrupted in that case? As I mentioned just now in yet another message, we impose a threshold. N quits in T milliseconds -> upgrade quit to immediate-quit when we Fsignal, with quit on immediate-quit's condition list, just like we do for minibuffer-quit. immediate-quit means "I definitely meant to exit whatever I'm doing, even if the code says to read an event or key sequence". N_emergency quits in T_emergency milliseconds -> do same as above, except that we ignore inhibit-quit when deciding whether to signal: /* Have we gotten at least N quits in last T milliseconds? */ static bool check_recent_quits (int n, int t) { return ; } void probably_quit (void) { specpdl_ref gc_count = inhibit_garbage_collection (); /* Quit promptly if processing pending signals makes us want to quit. */ if (!QUITP && pending_signals) process_pending_signals (); if (QUITP || check_recent_quit(quit_emergency_count, quit_emergency_window)) process_quit_flag (); unbind_to (gc_count, Qnil); } and then, Lisp_Object quit (void) { bool upgrade = check_recent_quit (quit_upgrade_count, quit_upgrade_count); /* Only non-upgraded quits count as continuable. */ return signal_or_quit (upgrade ? Qquit_immediate : Qquit, Qnil, !upgrade); } and then in read_char, we change from if (convert_quits && !NILP (Vquit_flag)) { Vquit_flag = Qnil; result = make_fixnum (quit_char); } to if (convert_quits && !NILP (Vquit_flag) && check_recent_quit(quit_upgrade_count, quit_upgrade_count)) { Vquit_flag = Qnil; result = make_fixnum (quit_char); } and then... DEFVAR_INT ("quit-upgrade-count", quit_upgrade_count, doc: /* Number of quits received in quit-upgrade-period to count as an urgent quit that quits out of functions meant to read input events. */) quit_upgrade_count = 3; DEFVAR_INT ("quit-upgrade-period", quit_upgrade_period, doc: /* Time in which if we see at least quit-upgrade-count quits we quit out of functions meant to read input events. */) quit_upgrade_period = 500; DEFVAR_INT ("quit-emergency-count", quit_emergency_count, doc: /* Number of quits received in quit-emergency-period after which we disable safeguards that normally prevent quitting from protected code paths. */); quit_emergency_count = 6; a DEFVAR_INT ("quit-emergency-period", quit_emergency_period, doc: {you get the idea}); quit_emergency_period = 1000; At the top of command_loop_1, we reset the quit ring. The above thresholds count only between command invocations. TIMTOWTDI of course. This is a sketch. But something like this should make us both happy, yes? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 05:53:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174979397727914 (code B ref 78737); Fri, 13 Jun 2025 05:53:05 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 05:52:57 +0000 Received: from localhost ([127.0.0.1]:37389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPxLS-0007Fs-Ag for submit@debbugs.gnu.org; Fri, 13 Jun 2025 01:52:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58624) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPxLN-0007ES-LH for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 01:52:51 -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 1uPxLG-0006W1-1B; Fri, 13 Jun 2025 01:52:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=Wc7YwA1rmP3mdRqBMwrkYn6WufQjrYO+ne0GuRY2PrI=; b=Gg8XH/eXYAlySYY76EKl u63xNJexfvAcrm9fz8glmn9J/6Tu66SQR03npDljOe7up5H2D9hMXBqsDmBHEom6w1mfeTnuciWUi docpaGwN0ipUQYuFmTY4+RCKA3ZKSGlumONPiYzooJw/e0kgTtiv85RIPgQ5LizEENIqWKIlPuAGT rqnIJTLabYFjBN8QqrzuHqFpulDxpsi3GLb8LEGSvO5FVGHYbUkS3cjsuRX20Z7C4oCbyU7y7Bwee /FPuM2q6vFWnwvx2sK9/+HlPVQ8hyB5sxICCMtAkChbYrbM9XhAv4D5vaVz7FNP3xS7xO56qfn13g 6/jirFmNy4jPPg==; Date: Fri, 13 Jun 2025 08:52:40 +0300 Message-Id: <86tt4kdw7r.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <875xh0ztz2.fsf@protonmail.com> (message from Pip Cet on Thu, 12 Jun 2025 18:37:58 +0000) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) 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: Thu, 12 Jun 2025 18:37:58 +0000 > From: Pip Cet > Cc: dancol@dancol.org, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > > "Eli Zaretskii" writes: > > > Please describe the situations where you'd like it to throw to top > > level and it doesn't now. > > One situation for ordinary quits; three for force-quit. > > Situation 1: > > I'd like read-event, when called while inhibit-quit is t, to report > quits by setting quit-flag in addition to returning quit_char: it'll > simplify the C code, and it would make > > (while t > (let ((inhibit-quit t)) > (read-event))) > > quittable, as I naively expected it to be. The old behavior would > remain available, but require an extra let binding. But isn't it confusing that to have something quittable one needs to bind inhibit-quit non-nil? The naïve expectation from this is that the code affected by inhibit-quit non-nil is _not_ quittable, no? > Note that this isn't > > (let ((inhibit-quit t)) > (while t > (read-event))) Which is also confusing by its inconsistency. In general, the order of let-bindings doesn't matter. > Situation 3: > > Several force-quits in the same session. Reset force_quit_count to 0 > once it reaches 3. I've seen force_quit_count reach higher values than > 3 (there was no regular quit in between force quit attempts). If you are talking about a GUI session, then IME the 'emergency exit" procedure isn't reliably working in that case, and I'm not sure the implementation intends to support that. I always knew that it's only reliably working on TTY frames. Or are you talking about the effect of the changes on the branch? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 06:26:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174979595519107 (code B ref 78737); Fri, 13 Jun 2025 06:26:03 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 06:25:55 +0000 Received: from localhost ([127.0.0.1]:37477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPxrM-0004xj-DX for submit@debbugs.gnu.org; Fri, 13 Jun 2025 02:25:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55832) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPxrG-0004vg-K1 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 02:25:49 -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 1uPxr9-00032q-Sc; Fri, 13 Jun 2025 02:25:39 -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=GwIkOtEePFCMsegVLUdDHz0L6cwx//uLeKhUDwJ83bU=; b=SAVd4XNJnx8z 7RLQQlVThNYrb7E2dt9D6nPUKx8hA1dv7ymXs7dlpyj3ccOt3K+BBaCwCvSs8N4v95habIu0irl2u 5stVks6WTjJjCnfw+XFcFp4okMwi4uVuUHrQ/t9493mOFIkODMuHQ7E5ZWQTPJaXZCCOXkA82srnv /hh+y8fYMqAVkEvILBSGHrfkEjl2P1I9rj2ManXxyQN6fqmGmY8Ijrmz71HYOiMnqdaatlPWN7ZIe HWKjwX1TZIqFNWGp6dH0kerMCb8NumIvHPLctnPMZ+PjuQlMQNduaG1+hBRmqGtGWteYxfoNKw/xn koJd5Bt+SMU+wEUcO6rJ9A==; Date: Fri, 13 Jun 2025 09:25:36 +0300 Message-Id: <86sek4duov.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Thu, 12 Jun 2025 11:48:50 -0700) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> X-Spam-Score: -2.3 (--) 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 (---) > From: Daniel Colascione > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, > 78737@debbugs.gnu.org > Date: Thu, 12 Jun 2025 11:48:50 -0700 > > Pip Cet writes: > > > I'd like read-event, when called while inhibit-quit is t, to report > > quits by setting quit-flag in addition to returning quit_char: it'll > > simplify the C code, and it would make > > > > (while t > > (let ((inhibit-quit t)) > > (read-event))) > > I strongly disagree. read-event should read an event. > Setting quit-flag by side effect when it happens to read one key and not > others makes the interface less regular and understandable. We should start by agreeing that the capability of interrupting a running Lisp program is a real need. Are we in agreement about that? If not, let's first hear the arguments why not. If we _are_ in agreement about that, we should discuss how this should be possible if read-event (and perhaps others?) return C-g instead of raising quit-flag. The alternatives mentioned until now are: . restore the old behavior, whereby C-g interrupts read-event . have a variable that, if set, will restore the old behavior in read-event and other affected primitives, to be interruptible by a single C-g . make two C-g presses "in quick succession" set quit-flag, IOW "C-g C-g" will have the same effect as C-g previously Are there other alternatives? > read-key-sequence is the high-level function. read-event is the > low-level function. It makes zero sense for the high-level function to > report a key event as a low-level event and for the low-level function > to do special non-local flow control in response to that event. > > > quittable, as I naively expected it to be. > > The naive expectation is that this function do its job. I don't think there's disagreement on that level. So let's drop this kind of arguments, because they are not useful for this discussion. The problem we face is how to allow Lisp code to be quittable. A Lisp program that calls read-event is not different from a Lisp program calling any other function, so we still need such programs to be quittable somehow. Let's discuss how best to do it, okay? > > Several force-quits in the same session. Reset force_quit_count to 0 > > once it reaches 3. I've seen force_quit_count reach higher values than > > 3 (there was no regular quit in between force quit attempts). > > Get rid of force_quit_count entirely and just detect (by writing into a > ring buffer) whether we've received N quits in the last T milliseconds. > That'll work the same way regardless of how quits gets detected. We can > change N and T freely. This is the last alternative I described above. It is IMO less desirable, because it is not always easy to press C-g twice quickly, for whatever reasons. It is even less desirable to define "quick succession" in terms of time, because timings can differ a lot depending on the free computing resources and the CPU power in general, so determining the best default values will be very challenging, to say the least. > On your Emacs, you can set N to one and T to zero. If read-event still returns a keyboard input event when C-g is pressed, I don't see how N = 1 would work. Can you describe how it would work? > >> Also, can this behavior be optional, like debug-on-error and friends > >> are? Not everyone debugs Lisp code all the time, so we definitely can > >> have an "easy-break-out" feature that is by default off. > > > Absolutely. We could easily make it customizable whether read-event > > sets quit-flag after a quit: > > > > 1. never > > 2. only when !inhibit-quit > > 3. always > > We can customize thresholds for general behavior, but I don't think we > should not have preferences that alter the operation of fundamental > Emacs primitives. You couldn't add a preference that made if regard 0 > as well as nil as false, would you? Why not? If it helps debugging, we could definitely do that. We already have --enable-checking, which changes how some primitives work, in a very real sense. As long as the feature is for debugging Emacs, anything useful goes, IMO. > >>> Maybe a compromise would be to continue the arms race and downgrade C-g > >>> to normal input, C-g C-g C-g to a quit, and require even more C-g's for > >>> a force-quit? > >> > >> That's also possible, though less desirable: counting C-g presses when > >> you are desperate is not easy and we cannot rely on users to do that > >> reliably. > > > > And we'd need a way to detect when a quit is handled (however we define > > "handled") so we could reset force_quit_counter. Not a trivial change. > > You don't. You just upgrade any quit that happens under the N and T > threshold above. I'm skeptical that we will be able to count C-g presses so as to reliably differentiate between double or triple press and two or three separate C-g presses. Different machines and OSes, and different system loads, can make it nigh impossible to do reliably. And that's _bad_, because when I want something interrupted right away, I don't want or even cannot try again and again and again until it works. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 07:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174979974632568 (code B ref 78737); Fri, 13 Jun 2025 07:30:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 07:29:06 +0000 Received: from localhost ([127.0.0.1]:37672 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPyqX-0008TD-A5 for submit@debbugs.gnu.org; Fri, 13 Jun 2025 03:29:05 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:57066) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPyqP-0008RX-4n for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 03:29:02 -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:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: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=Yqid1CBh4FOoBsFqq38NweIZAFNyyeQTW5z0vntemHE=; b=P+fkK01F+rS4uFc4L81nqw5y2E mlyNw+piA3ADQkQVuyBgTDR5grkvJ32ZOmmxCIEBEv7Vb/VjPMtbv6cfeKZgqyjddrNlyOjnT4K9q y+x5zJq5O6KuZkFoLkQ0ZcUR1TFaWXv/CAhC2x2mXVz78D1QkOq3sv19aEUNBycAqeG3Hi9/aJ9Wo qeAkp8VoiV8rrw39tQaQoWbGuzZmLPMsMaemsxkBdwl67yqm15/7sXFtSEps93sO0baoCnIM9psIc J6iLGHx9yJwB5SayABgpExWHbGID6esTDDSAW9ZJcJzrhP7gwG1/bJd8I3Gv67/RAhbzDpqfcxYVo rU1x/10A==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPyou-00Bs13-1H; Fri, 13 Jun 2025 03:27:24 -0400 From: Daniel Colascione In-Reply-To: <86sek4duov.fsf@gnu.org> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Fri, 13 Jun 2025 00:28:45 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) 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 (-) Eli Zaretskii writes: >> From: Daniel Colascione >> Cc: Eli Zaretskii , monnier@iro.umontreal.ca, >> 78737@debbugs.gnu.org >> Date: Thu, 12 Jun 2025 11:48:50 -0700 >> >> Pip Cet writes: >> >> > I'd like read-event, when called while inhibit-quit is t, to report >> > quits by setting quit-flag in addition to returning quit_char: it'll >> > simplify the C code, and it would make >> > >> > (while t >> > (let ((inhibit-quit t)) >> > (read-event))) >> >> I strongly disagree. read-event should read an event. >> Setting quit-flag by side effect when it happens to read one key and not >> others makes the interface less regular and understandable. > > We should start by agreeing that the capability of interrupting a > running Lisp program is a real need. Are we in agreement about that? > If not, let's first hear the arguments why not. Which Lisp programs? One that calls (while t (read-event))? One that calls (let ((inhibit-quit t)) (while t (read-event))? How about one that calls (while t (read-key-sequence ""))? How about one that calls (let ((inhibit-quit t)) (while t (read-key-sequence ""))? If you adopt the tenet that Lisp programs always be uninterruptible, _something_ has to change from the present, because 3/4 of my examples above cannot be quit. (Today's force quit doesn't count: it doesn't practically work outside primary TTY.) > If we _are_ in agreement about that, we should discuss how this should > be possible if read-event (and perhaps others?) return C-g instead of > raising quit-flag. The alternatives mentioned until now are: > > . restore the old behavior, whereby C-g interrupts read-event Does not satisfy the "lisp programs always be interruptible" requirement. > . have a variable that, if set, will restore the old behavior in Same as above. > read-event and other affected primitives, to be interruptible by a > single C-g Same as above. > . make two C-g presses "in quick succession" set quit-flag, IOW > "C-g C-g" will have the same effect as C-g previously Only for read-event. If you want to adopt a principled stance that every Lisp program be interruptible, you necessarily, as a matter of logic, regard multiple behaviors of current Emacs to be bugs worth fixing. > Are there other alternatives? Get in a time machine, go back 40 years and stop overloading C-g? >> read-key-sequence is the high-level function. read-event is the >> low-level function. It makes zero sense for the high-level function to >> report a key event as a low-level event and for the low-level function >> to do special non-local flow control in response to that event. >> >> > quittable, as I naively expected it to be. >> >> The naive expectation is that this function do its job. > > I don't think there's disagreement on that level. So let's drop this > kind of arguments, because they are not useful for this discussion. > The problem we face is how to allow Lisp code to be quittable. A Lisp > program that calls read-event is not different from a Lisp program > calling any other function, so we still need such programs to be > quittable somehow. Let's discuss how best to do it, okay? Yes or no: should (while t (read-key-sequence)) be quittable? If yes, maintaining today's behavior isn't an option. There are plenty of other Lisp programs that cannot be quit --- even (let ((inhibit-quit t)) (while t)) cannot be quit! If no, what is the problem with cleaning up Emacs by regularizing how we treat C-g as an event versus some kind of longjmp? >> > Several force-quits in the same session. Reset force_quit_count to 0 >> > once it reaches 3. I've seen force_quit_count reach higher values than >> > 3 (there was no regular quit in between force quit attempts). >> >> Get rid of force_quit_count entirely and just detect (by writing into a >> ring buffer) whether we've received N quits in the last T milliseconds. >> That'll work the same way regardless of how quits gets detected. We can >> change N and T freely. > > This is the last alternative I described above. It is IMO less > desirable, because it is not always easy to press C-g twice quickly, > for whatever reasons. It is even less desirable to define "quick > succession" in terms of time, because timings can differ a lot > depending on the free computing resources and the CPU power in > general, so determining the best default values will be very > challenging, to say the least. I don't see the ambiguity being a realistic problem. How often do you press C-g three times while a single command is running? We're not talking about, say, six times in multiple rounds of M-x this, select that, deactivate mark over here. Those are multiple commands. In between multiple commands, a C-g will cause a keyboard-quit and you'll regain control over Emacs. I'm asking, during _one_ command, how many times you typically press C-g and _don't_ mean it as a quit. We already have a force quit mechanism that kicks in at N=3. How often do you activate it? >> On your Emacs, you can set N to one and T to zero. > > If read-event still returns a keyboard input event when C-g is > pressed, I don't see how N = 1 would work. Can you describe how it > would work? It wouldn't. Such a setting would prevent read-input returning C-g. That shouldn't be the default. Maybe some people would customize the setting to make Emacs behave this way. I would not. >> >> Also, can this behavior be optional, like debug-on-error and friends >> >> are? Not everyone debugs Lisp code all the time, so we definitely can >> >> have an "easy-break-out" feature that is by default off. >> >> > Absolutely. We could easily make it customizable whether read-event >> > sets quit-flag after a quit: >> > >> > 1. never >> > 2. only when !inhibit-quit >> > 3. always >> >> We can customize thresholds for general behavior, but I don't think we >> should not have preferences that alter the operation of fundamental >> Emacs primitives. You couldn't add a preference that made if regard 0 >> as well as nil as false, would you? > > Why not? If it helps debugging, we could definitely do that. We > already have --enable-checking, which changes how some primitives > work, in a very real sense. As long as the feature is for debugging > Emacs, anything useful goes, IMO. Because when you add a user option, people expect code you write to operate under any value of that option, increasing implementation complexity because you have to account for the _possibility_ someone might operate in a certain way. Complexity is insidious, and the solution to a technical problem is rarely to add yet another technical knob nobody is going to realistically touch but for which logic must account. >> >>> Maybe a compromise would be to continue the arms race and downgrade C-g >> >>> to normal input, C-g C-g C-g to a quit, and require even more C-g's for >> >>> a force-quit? >> >> >> >> That's also possible, though less desirable: counting C-g presses when >> >> you are desperate is not easy and we cannot rely on users to do that >> >> reliably. >> > >> > And we'd need a way to detect when a quit is handled (however we define >> > "handled") so we could reset force_quit_counter. Not a trivial change. >> >> You don't. You just upgrade any quit that happens under the N and T >> threshold above. > > I'm skeptical that we will be able to count C-g presses so as to > reliably differentiate between double or triple press and two or three > separate C-g presses. There is logically no difference between these two concepts. A double keypress *is* two keypresses in a certain window of time. What other concept could the combination of the words "double" and "press" convey? > Different machines and OSes, and different > system loads, can make it nigh impossible to do reliably. And that's > _bad_, because when I want something interrupted right away, I don't > want or even cannot try again and again and again until it works. Then define a separate key that means _only_ quit and that cannot be bound to a regular command. C-g can't be that command without breaking existing code. Treating repeated C-g presses made in a reasonable window of time within the scope of a single command in such a way that we're almost certainly not confusing this series of keystrokes with C-g-as-command input solves the problem. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 07:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, Pip Cet , monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498012359317 (code B ref 78737); Fri, 13 Jun 2025 07:54:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 07:53:55 +0000 Received: from localhost ([127.0.0.1]:38333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uPzEY-0002QD-Oq for submit@debbugs.gnu.org; Fri, 13 Jun 2025 03:53:55 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:49556) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uPzEU-0002Py-P1 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 03:53:52 -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:Date: References:In-Reply-To:Subject:Cc:To:From: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=kCzsZrRXxERQ6dx63BqCRD06z38mt0CC8RLa9MZkfo8=; b=BUaUn8gGFTa20jE4KxKYKFKQ+6 jw5q7YGoSptOvk3UiS3ixLFG1LIaGfoSq6+oSVaL1/rBZV/xEASv+jQ0faPa5Dv9dtfhCpkF3nXNE E1RLpPVhjmCjvYkWxMFHuS5RbqLswz0EYO0VrE5Gd4xv3IZoA+wndDtDP+EF2hSJAS2R3sQSNNEOG R43x6H2xolQMH3lex3qhdaRCRE4fAt85KkOXYPe5YJ1+f7TSGo652hPFvPKw2ULAVUYAZGcjfxj4v Tvr3806/8v67qIHnvl6HYsNMEhydpAP/X2SKkP5ylnX5yCGQt9L7dASPjEjBy0W51+AywyoTgg5WF YtgNAStA==; Received: from dancol by dancol.org with local (Exim 4.96) (envelope-from ) id 1uPzCz-00BsUD-1P; Fri, 13 Jun 2025 03:52:17 -0400 From: Daniel Colascione In-Reply-To: <86tt4kdw7r.fsf@gnu.org> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86tt4kdw7r.fsf@gnu.org> User-Agent: mu4e 1.12.10; emacs 31.0.50 Date: Fri, 13 Jun 2025 00:53:38 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 (-) Eli Zaretskii writes: >> Date: Thu, 12 Jun 2025 18:37:58 +0000 >> From: Pip Cet >> Cc: dancol@dancol.org, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >>=20 >> "Eli Zaretskii" writes: >>=20 >> > Please describe the situations where you'd like it to throw to top >> > level and it doesn't now. >>=20 >> One situation for ordinary quits; three for force-quit. >>=20 >> Situation 1: >>=20 >> I'd like read-event, when called while inhibit-quit is t, to report >> quits by setting quit-flag in addition to returning quit_char: it'll >> simplify the C code, and it would make >>=20 >> (while t >> (let ((inhibit-quit t)) >> (read-event))) >>=20 >> quittable, as I naively expected it to be. The old behavior would >> remain available, but require an extra let binding. > > But isn't it confusing that to have something quittable one needs to > bind inhibit-quit non-nil? The na=C3=AFve expectation from this is that > the code affected by inhibit-quit non-nil is _not_ quittable, no? > >> Note that this isn't >>=20 >> (let ((inhibit-quit t)) >> (while t >> (read-event))) > > Which is also confusing by its inconsistency. In general, the order > of let-bindings doesn't matter. > >> Situation 3: >>=20 >> Several force-quits in the same session. Reset force_quit_count to 0 >> once it reaches 3. I've seen force_quit_count reach higher values than >> 3 (there was no regular quit in between force quit attempts). > > If you are talking about a GUI session, then IME the 'emergency exit" > procedure isn't reliably working in that case, and I'm not sure the > implementation intends to support that. I always knew that it's only > reliably working on TTY frames. > > Or are you talking about the effect of the changes on the branch? FWIW, the purpose of my N-times-in-T-milliseconds-within-one-command formulation of emergency exit is to get the mechanism working reliably in all cases. I can definitely type 4-5 C-gs in a GUI Emacs (well, NS, but I recall PGTK being similar?) and not have Emacs quit. If I mash C-g, it sometimes does, and sometimes doesn't. Right now, the logic is this: { /* Request quit when it's safe. */ int count =3D NILP (Vquit_flag) ? 1 : force_quit_count + 1; force_quit_count =3D count; if (count =3D=3D 3) Vinhibit_quit =3D Qnil; Vquit_flag =3D Qt; } IOW, the first quit after clearing Vquit_flag resets the count to one. Maybe that's why it isn't working reliably right now. If we reformulate this mechanism not in terms of count =3D=3D 3 (which is fiddly for all sorts of reasons, since Vquit_flag can get reset) but in terms of the UX directly --- N recent quits in T time in a single command --- we make the whole thing more reliable. If you set T=3Dinfinity and N=3D3, you get the current force quit UX (modulo my upgrade-before-disabling-inhibit-quit thing), just more reliably, and you can break out of arbitrary Lisp code. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 11:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498144604773 (code B ref 78737); Fri, 13 Jun 2025 11:35:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 11:34:20 +0000 Received: from localhost ([127.0.0.1]:42820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ2fr-0001Eu-A6 for submit@debbugs.gnu.org; Fri, 13 Jun 2025 07:34:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34944) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ2fn-0001Ec-Ff for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 07:34:16 -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 1uQ2fg-0002rQ-M9; Fri, 13 Jun 2025 07:34:08 -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=ieZS1dwJW5ekUwGR01+sK6wW4Ciw77k4s4sEl+jcWyA=; b=fXIxBYvRoh7I x60TKlk2bNJ2lpt86J4E2RTTW9gc6qny6YimCX7YDfXXPtjLqB8+ML0HFQ7Eeaed4AAQd5nkrlFVA ZyahBXhRUhrCBeuDQEfY19OaI8zd8K2Wnl/nvBce+htz1V+6eXjtvAMh1uvbawJLqaTP9DTuHalVj H5dtRVQLtXPGClF8uMXRC+X+j89S2RO3if00d5Vl69YmmAVYIpLgXHcrP8pz6DXpKa7SA8tmKTlca n/eUmictG4X04xyJjj02EOY82/pg5C8/Tb9QTaNMDePIONwWQ8/hI8L+593eEkK3gz8xDTvbDdeKO 5v4Cy2+7zX11HjnWiioZpQ==; Date: Fri, 13 Jun 2025 14:34:06 +0300 Message-Id: <86frg3euz5.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Fri, 13 Jun 2025 00:28:45 -0700) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Daniel Colascione > Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > Date: Fri, 13 Jun 2025 00:28:45 -0700 > > Eli Zaretskii writes: > > >> From: Daniel Colascione > >> Cc: Eli Zaretskii , monnier@iro.umontreal.ca, > >> 78737@debbugs.gnu.org > >> Date: Thu, 12 Jun 2025 11:48:50 -0700 > >> > >> Pip Cet writes: > >> > >> > I'd like read-event, when called while inhibit-quit is t, to report > >> > quits by setting quit-flag in addition to returning quit_char: it'll > >> > simplify the C code, and it would make > >> > > >> > (while t > >> > (let ((inhibit-quit t)) > >> > (read-event))) > >> > >> I strongly disagree. read-event should read an event. > >> Setting quit-flag by side effect when it happens to read one key and not > >> others makes the interface less regular and understandable. > > > > We should start by agreeing that the capability of interrupting a > > running Lisp program is a real need. Are we in agreement about that? > > If not, let's first hear the arguments why not. > > Which Lisp programs? All of them. > One that calls (while t (read-event))? One that > calls (let ((inhibit-quit t)) (while t (read-event))? How about one > that calls (while t (read-key-sequence ""))? How about one that calls > (let ((inhibit-quit t)) (while t (read-key-sequence ""))? If you adopt > the tenet that Lisp programs always be uninterruptible, _something_ has > to change from the present, because 3/4 of my examples above cannot > be quit. So because we currently cannot interrupt some programs we should give up the ability to interrupt all of them? Please be serious. Arguments like the above are a red herring, and don't help advancing this discussion towards some kind of agreement. Do you want the branch merged at some point? Then please drop the attitude and start participating in the discussion seriously. You understand very well what I meant above, even though it is somewhat vague. We all know what Emacs can and cannot do today, so I allow myself not to write too many well-known details. Let's consider the current capabilities of interrupting Lisp programs as base line, and try to maintain that base line, if not improve on it. Okay? Or does it still not satisfy your intentionally-pedantic interpretation of what I write? > > If we _are_ in agreement about that, we should discuss how this should > > be possible if read-event (and perhaps others?) return C-g instead of > > raising quit-flag. The alternatives mentioned until now are: > > > > . restore the old behavior, whereby C-g interrupts read-event > > Does not satisfy the "lisp programs always be > interruptible" requirement. > > > . have a variable that, if set, will restore the old behavior in > > Same as above. > > > read-event and other affected primitives, to be interruptible by a > > single C-g > > Same as above. Please reconsider your responses with a more serious and cooperative attitude. > > . make two C-g presses "in quick succession" set quit-flag, IOW > > "C-g C-g" will have the same effect as C-g previously > > Only for read-event. Why "only"? Having the behavior vary depending on whether the program does or doesn't call read-event will bring inconsistency, something we want to avoid (and which I think you argued against). > If you want to adopt a principled stance that every Lisp program be > interruptible, you necessarily, as a matter of logic, regard multiple > behaviors of current Emacs to be bugs worth fixing. Not useful. I didn't mean that, and you know it. > > Are there other alternatives? > > Get in a time machine, go back 40 years and stop overloading C-g? Even less useful. Again, do you want this branch to be merged any time soon? Because I'm this close to losing my patience. Life's too short to waste it on "arguments" such as this one. > > I don't think there's disagreement on that level. So let's drop this > > kind of arguments, because they are not useful for this discussion. > > The problem we face is how to allow Lisp code to be quittable. A Lisp > > program that calls read-event is not different from a Lisp program > > calling any other function, so we still need such programs to be > > quittable somehow. Let's discuss how best to do it, okay? > > Yes or no: should (while t (read-key-sequence)) be quittable? Why is that relevant? I asked about read-event, not read-key-sequence. Can we first discuss the read-event case? Once we are done with that, we can move to other cases. > If yes, maintaining today's behavior isn't an option. There are plenty > of other Lisp programs that cannot be quit --- even (let ((inhibit-quit > t)) (while t)) cannot be quit! If inhibit-quit is bound to a non-nil value, the program cannot be quit, and that's a feature. Why are we discussing this? > If no, what is the problem with cleaning up Emacs by regularizing how we > treat C-g as an event versus some kind of longjmp? Again, let's discuss the read-key-sequence case after we are done with the read-event case. > >> > Several force-quits in the same session. Reset force_quit_count to 0 > >> > once it reaches 3. I've seen force_quit_count reach higher values than > >> > 3 (there was no regular quit in between force quit attempts). > >> > >> Get rid of force_quit_count entirely and just detect (by writing into a > >> ring buffer) whether we've received N quits in the last T milliseconds. > >> That'll work the same way regardless of how quits gets detected. We can > >> change N and T freely. > > > > This is the last alternative I described above. It is IMO less > > desirable, because it is not always easy to press C-g twice quickly, > > for whatever reasons. It is even less desirable to define "quick > > succession" in terms of time, because timings can differ a lot > > depending on the free computing resources and the CPU power in > > general, so determining the best default values will be very > > challenging, to say the least. > > I don't see the ambiguity being a realistic problem. How often do you > press C-g three times while a single command is running? I usually expect a single C-g to quit. If it doesn't help, I can press C-g several times, I'm not sure I count them. > We're not talking about, say, six times in multiple rounds of M-x this, > select that, deactivate mark over here. Those are multiple commands. > In between multiple commands, a C-g will cause a keyboard-quit and > you'll regain control over Emacs. I'm asking, during _one_ command, how > many times you typically press C-g and _don't_ mean it as a quit. See above. > We already have a force quit mechanism that kicks in at N=3. How often > do you activate it? I never saw it at work, except on TTY frames. But then Windows doesn't have SIGIO, it emulates that. Maybe that's the reason. > >> On your Emacs, you can set N to one and T to zero. > > > > If read-event still returns a keyboard input event when C-g is > > pressed, I don't see how N = 1 would work. Can you describe how it > > would work? > > It wouldn't. Such a setting would prevent read-input returning C-g. > That shouldn't be the default. Sorry, I don't understand. If N = 1, what will read-event do when the user presses C-g while inside read-event? Will it return the input event C-g, or will it quit? I thought your changes make read-event always return the input event, was I mistaken? > >> We can customize thresholds for general behavior, but I don't think we > >> should not have preferences that alter the operation of fundamental > >> Emacs primitives. You couldn't add a preference that made if regard 0 > >> as well as nil as false, would you? > > > > Why not? If it helps debugging, we could definitely do that. We > > already have --enable-checking, which changes how some primitives > > work, in a very real sense. As long as the feature is for debugging > > Emacs, anything useful goes, IMO. > > Because when you add a user option, people expect code you write to > operate under any value of that option, increasing implementation > complexity because you have to account for the _possibility_ someone > might operate in a certain way. No, people need not expect the code to operate the same under those special debugging-oriented values. We already have such features: debug-on-error = t might well cause some command cease working normally, and similarly condition-case-unless-debug. So I think you are bothered by a problem that doesn't need to be solved. > >> >>> Maybe a compromise would be to continue the arms race and downgrade C-g > >> >>> to normal input, C-g C-g C-g to a quit, and require even more C-g's for > >> >>> a force-quit? > >> >> > >> >> That's also possible, though less desirable: counting C-g presses when > >> >> you are desperate is not easy and we cannot rely on users to do that > >> >> reliably. > >> > > >> > And we'd need a way to detect when a quit is handled (however we define > >> > "handled") so we could reset force_quit_counter. Not a trivial change. > >> > >> You don't. You just upgrade any quit that happens under the N and T > >> threshold above. > > > > I'm skeptical that we will be able to count C-g presses so as to > > reliably differentiate between double or triple press and two or three > > separate C-g presses. > > There is logically no difference between these two concepts. A double > keypress *is* two keypresses in a certain window of time. What other > concept could the combination of the words "double" and "press" convey? I don't understand what you are saying here. Yes, there's no logical difference between these, which is why I'm saying that reliably detecting "double C-g" is a challenge. We already have that with double-mouse. The difference between double-mouse and "double C-g" is that with the latter you cannot afford low reliability: when you want to quit, you want to do it immediately, because the runaway operation you want to interrupt could be harmful. > > Different machines and OSes, and different > > system loads, can make it nigh impossible to do reliably. And that's > > _bad_, because when I want something interrupted right away, I don't > > want or even cannot try again and again and again until it works. > > Then define a separate key that means _only_ quit and that cannot be > bound to a regular command. C-g can't be that command without breaking > existing code. It's too late to define a separate key _instead_ of C-g. We could define a separate key _in_addition_ to C-g, but that doesn't solve the problem: people have C-g hardwired into their muscle memory, and it will take a lot of time for them to re-learn. Meanwhile, we get bug reports about C-g not working like it did before. So minimizing the behavior changes is still a requirement, even if we add another key. And that's before we even consider what other key could serve that purpose, which is not a trivial problem to solve portably. > Treating repeated C-g presses made in a reasonable window of time within > the scope of a single command in such a way that we're almost certainly > not confusing this series of keystrokes with C-g-as-command input solves > the problem. That's possible, but it is not the best alternative IMO, for the reasons I explained. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 11:37:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498146215730 (code B ref 78737); Fri, 13 Jun 2025 11:37:06 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 11:37:01 +0000 Received: from localhost ([127.0.0.1]:42864 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ2iP-0001UA-VF for submit@debbugs.gnu.org; Fri, 13 Jun 2025 07:37:00 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36904) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ2iL-0001Ss-58 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 07:36: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 1uQ2iF-0003Tc-BB; Fri, 13 Jun 2025 07:36:47 -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=6xWSnJQhV2GgccmSHXuFl0CwTi26q8GJMJYWAN9gpW4=; b=cgQ/kNZdgcoP V3a1fLokKvw11q8eTmOdJGpU4klWxojf2NJtqEvrgAj87ZkLrxd6TjnJCLg3WTROyDjsggFpHCm7I tuPJ/SK//yoAfvrBYxByBalrppkE8VYG4wQxCMRNi7uKAInrYNn7pKPlFAlBdhfeoCGdBtDxaIVVD pxccdhrBQuPfkt0t5N2aLaWOSfj0z187BZ8hGAUTBpiMu0RH7QkAqyZV4ooMG/4+3p33cBhD1ILJz PL+vTh6rdKn6Sae034xjgU/wvM0ry34hNpm7hTQUTRdawORExT2mRIEEQ88Snv3FZz/MpYP8LP68b JpHKtZv+K2GYsMpVCCxgvg==; Date: Fri, 13 Jun 2025 14:36:42 +0300 Message-Id: <86ecvneuut.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Fri, 13 Jun 2025 00:53:38 -0700) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86tt4kdw7r.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Daniel Colascione > Cc: Pip Cet , monnier@iro.umontreal.ca, > 78737@debbugs.gnu.org > Date: Fri, 13 Jun 2025 00:53:38 -0700 > > > If you are talking about a GUI session, then IME the 'emergency exit" > > procedure isn't reliably working in that case, and I'm not sure the > > implementation intends to support that. I always knew that it's only > > reliably working on TTY frames. > > > > Or are you talking about the effect of the changes on the branch? > > FWIW, the purpose of my N-times-in-T-milliseconds-within-one-command > formulation of emergency exit is to get the mechanism working reliably > in all cases. > > I can definitely type 4-5 C-gs in a GUI Emacs (well, NS, but I recall > PGTK being similar?) and not have Emacs quit. If I mash C-g, it > sometimes does, and sometimes doesn't. > > Right now, the logic is this: > > { > /* Request quit when it's safe. */ > int count = NILP (Vquit_flag) ? 1 : force_quit_count + 1; > force_quit_count = count; > if (count == 3) > Vinhibit_quit = Qnil; > Vquit_flag = Qt; > } > > IOW, the first quit after clearing Vquit_flag resets the count to one. > Maybe that's why it isn't working reliably right now. If we reformulate > this mechanism not in terms of count == 3 (which is fiddly for all sorts > of reasons, since Vquit_flag can get reset) but in terms of the UX > directly --- N recent quits in T time in a single command --- we make > the whole thing more reliable. > > If you set T=infinity and N=3, you get the current force quit UX (modulo > my upgrade-before-disabling-inhibit-quit thing), just more reliably, and > you can break out of arbitrary Lisp code. I suggest to leave the emergency exit feature alone for now, and focus on the interruptibility of Lisp programs. They are not independent, but the emergency exit is a separate feature, so mixing these two discussions makes the argument less effective. We can return to the emergency exit later. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 11:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498153809256 (code B ref 78737); Fri, 13 Jun 2025 11:50:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 11:49:40 +0000 Received: from localhost ([127.0.0.1]:43128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ2ue-0002P9-0F for submit@debbugs.gnu.org; Fri, 13 Jun 2025 07:49:39 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:40694) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ2ua-0002Oz-9d for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 07:49:33 -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=mxVaJG8VOVLfsW7+0AIPhqSxSY+kHUzwUpUHhAqCqgU=; b=P1pIxPVX82eENXai9Mj1luFHKc izaqcS+xC+7HtvQPHykqQcI+FsF+/lAivFr73Xl/ACPKVevxrNdxJwSbidFrwUr4F4qUSH+QAIzaB lewldfMCfl782T5ZAgV3vIGWF+JiprPGftkbmBTHToP9qqr7se67GJHc3d1eBGgFAtTYKD5IU4pqT nch5eyXUmHp6OZYyem+4gqkHPHuudMW+eQNaVwDd30vt2AtqTLhU7+ucu2qQ6HzKQtKRF9A0mmrDG aIg1o8aYPDRqUrBvpeakKooxASSpoUrzaRyFA0eatrlU4rJ4x7G2v5+Q+EMiYQzkGrEyRK6s+iJUF KhrY+WnA==; Received: from [2600:1010:b047:2f06:0:48:6379:f01] (port=48694 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 1uQ2t7-00BtIP-1x; Fri, 13 Jun 2025 07:48:01 -0400 Date: Fri, 13 Jun 2025 04:49:21 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <86ecvneuut.fsf@gnu.org> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86tt4kdw7r.fsf@gnu.org> <86ecvneuut.fsf@gnu.org> Message-ID: <8A57564E-70F3-49F6-8D77-1C947087DF8C@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 13, 2025 4:36:42 AM PDT, Eli Zaretskii wrote: >> From: Daniel Colascione >> Cc: Pip Cet , monnier@iro=2Eumontreal=2Eca, >> 78737@debbugs=2Egnu=2Eorg >> Date: Fri, 13 Jun 2025 00:53:38 -0700 >>=20 >> > If you are talking about a GUI session, then IME the 'emergency exit" >> > procedure isn't reliably working in that case, and I'm not sure the >> > implementation intends to support that=2E I always knew that it's on= ly >> > reliably working on TTY frames=2E >> > >> > Or are you talking about the effect of the changes on the branch? >>=20 >> FWIW, the purpose of my N-times-in-T-milliseconds-within-one-command >> formulation of emergency exit is to get the mechanism working reliably >> in all cases=2E >>=20 >> I can definitely type 4-5 C-gs in a GUI Emacs (well, NS, but I recall >> PGTK being similar?) and not have Emacs quit=2E If I mash C-g, it >> sometimes does, and sometimes doesn't=2E >>=20 >> Right now, the logic is this: >>=20 >> { >> /* Request quit when it's safe=2E */ >> int count =3D NILP (Vquit_flag) ? 1 : force_quit_count + 1; >> force_quit_count =3D count; >> if (count =3D=3D 3) >> Vinhibit_quit =3D Qnil; >> Vquit_flag =3D Qt; >> } >>=20 >> IOW, the first quit after clearing Vquit_flag resets the count to one= =2E >> Maybe that's why it isn't working reliably right now=2E If we reformul= ate >> this mechanism not in terms of count =3D=3D 3 (which is fiddly for all = sorts >> of reasons, since Vquit_flag can get reset) but in terms of the UX >> directly --- N recent quits in T time in a single command --- we make >> the whole thing more reliable=2E >>=20 >> If you set T=3Dinfinity and N=3D3, you get the current force quit UX (m= odulo >> my upgrade-before-disabling-inhibit-quit thing), just more reliably, an= d >> you can break out of arbitrary Lisp code=2E > >I suggest to leave the emergency exit feature alone for now, and focus >on the interruptibility of Lisp programs=2E That *is* the interruptabiltity of Lisp programs=2El From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Lynn Winebarger Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 12:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, Pip Cet , Daniel Colascione , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174981744018972 (code B ref 78737); Fri, 13 Jun 2025 12:24:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 12:24:00 +0000 Received: from localhost ([127.0.0.1]:43896 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ3Rv-0004vv-AQ for submit@debbugs.gnu.org; Fri, 13 Jun 2025 08:23:59 -0400 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:39602) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQ3Rr-0004vZ-0l for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 08:23:56 -0400 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3a4e575db1aso190871f8f.2 for <78737@debbugs.gnu.org>; Fri, 13 Jun 2025 05:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749817428; x=1750422228; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZxsWtnYfP/bS0lkc9uX0KdYC3sXksH4l6SVognXUHxc=; b=NubFus0i/94+gQ6AG5WRosOHpw/727cW15/NscpiKLXYThEL2e1JGm/8V2oowtoCHX NFmTZdNH+Ql59Mi4aX/HM5ahAFDdXKiWWN1SZTC/XdVaMTu4+XYZqMOqKaucDe6u3zHV tm5FYgQi7t9mhN6yk+QDxeOd+jSYB9XabGVKQPtxMhStpVjTymX7R63gFt/R9aUEqUKs 9QTATe1FaPLIyVN2UkZAAwi2J8yjrTb2pJfY+ZZtF92LApcs825BHjQ+mdnhU/4ChHol Cw/IGHKHB3FHbbKVYL20ULslLzLb7klTdFfq+WscS89/Q8VG5rswu/GKMTh60a/zF9k5 enrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749817428; x=1750422228; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZxsWtnYfP/bS0lkc9uX0KdYC3sXksH4l6SVognXUHxc=; b=hasSbKpP+iN0Dteh/0XVJzkepdnJTeDbjFU3JpYHPrN/sBeJpyVMPu/Fwr7RnCLyDW LR5vsBXXm/GqU8LyTfAU+1z9yLWWl+vPFh8h1uGl5kCMRVh8RD9J+6rwIPRT+/P0rPzT 1asysRZ50GInWYLUhVf0qQyDJMhap+Dx+7KLs+6Mkv20Hlv26wT51d7l+d2nUPbjftyH hPAvltZRe/35AV05MusZ80zPk24UTtY0xuV0AMJpO2yMzlXzamfNO190j4ab884ncYJI DJsLdwWDVR8xutO5SzMrFxrklz8zGJWYpcE2IEnXY0Q6yyRHafUIH4rd2zJlbu/GQArW j7TQ== X-Forwarded-Encrypted: i=1; AJvYcCX/j4Da3L95kdG/9H3nx5ohgtYJssjPHq/XpzG8sXr0IuuKtJ+5TWTXk+f242RFuVZ7A4d8pw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxM14QDblIXzpYqgPEXeXXTJl6Gf/KODwqG5Sy/yBr5dQhddnZo 3D5OeNqKss/VX5fUn0RyknWP1fPTiuP/dLyvgjlFjuNuZ4kofPItBLTNSHFHBt1xqQ8H+6k2izD w6q8rHZ3iYutxOqkCWd3r66V99bBnZ0s= X-Gm-Gg: ASbGncsv+azv2abA9sR5xG1KABHlvXf07emP0RHEE6Yv0hPQ8q0+L9E9u8pVgElR+Iu BrDJotOkcuOS0M/Zba/xZIX9fJe2ARXe/XbzTgU0zEaECY0xrqpcwALzPxyDPgCTOjHQiiebhIQ GmnZ1HjQfWvrCJ/QJX/5IkVwJmxuiqO86gGPDkVMoZBJqOMLbms9DSlaOtYsfLOcjNcK3v1kDyH PE= X-Google-Smtp-Source: AGHT+IF/DAjTA1NXV7ICQOK2gJM2h7E732unJ0gKUvPnPOWZQLu+ZarwZVSP33FGpCk2VFjDt3khBbNIvgqnp8R4bbM= X-Received: by 2002:a05:6000:310d:b0:3a5:2d42:aa1e with SMTP id ffacd0b85a97d-3a56875b1b0mr1062762f8f.15.1749817427790; Fri, 13 Jun 2025 05:23:47 -0700 (PDT) MIME-Version: 1.0 References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> In-Reply-To: <86sek4duov.fsf@gnu.org> From: Lynn Winebarger Date: Fri, 13 Jun 2025 08:23:34 -0400 X-Gm-Features: AX0GCFuvjmj0zAjSP6BF3-ufhmWCUgMG-7n_cF8umsSoeat0XJJyrZC4nQNZ9Ig Message-ID: Content-Type: multipart/alternative; boundary="0000000000003491200637731e85" X-Spam-Score: 0.0 (/) 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 (-) --0000000000003491200637731e85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jun 13, 2025, 2:26=E2=80=AFAM Eli Zaretskii wrote: > > From: Daniel Colascione > > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, > > 78737@debbugs.gnu.org > > Date: Thu, 12 Jun 2025 11:48:50 -0700 > > > > Pip Cet writes: > > > > > I'd like read-event, when called while inhibit-quit is t, to report > > > quits by setting quit-flag in addition to returning quit_char: it'll > > > simplify the C code, and it would make > > > > > > (while t > > > (let ((inhibit-quit t)) > > > (read-event))) > > > > I strongly disagree. read-event should read an event. > > Setting quit-flag by side effect when it happens to read one key and no= t > > others makes the interface less regular and understandable. > > We should start by agreeing that the capability of interrupting a > running Lisp program is a real need. Are we in agreement about that? > If not, let's first hear the arguments why not. > > If we _are_ in agreement about that, we should discuss how this should > be possible if read-event (and perhaps others?) return C-g instead of > raising quit-flag. The alternatives mentioned until now are: > > . restore the old behavior, whereby C-g interrupts read-event > . have a variable that, if set, will restore the old behavior in > read-event and other affected primitives, to be interruptible by a > single C-g > . make two C-g presses "in quick succession" set quit-flag, IOW > "C-g C-g" will have the same effect as C-g previously > > Are there other alternatives? > What about keeping a (possibly buffer-local?) lisp variable holding a list of keystrokes mapped to thunks that are treated as generating lisp machine "interrupts"? The key strokes would be processed by C machinery and never seen directly by lisp code and not be considered "events". Then C-g could be bound to a thunk signalling quit, and the effect of "inhibit-quit" achieved by removing C-g from the list in a given dynamic scope. Then user code could make other key-strokes "special" without resorting to read-event. For example, this read-event call in term.el: (message "Hit space to flush") (let ((ch (read-event))) (if (eq ch ?\s) (set-window-configuration conf) (push ch unread-command-events))) Could be replaced by something like (with-interrupts ((?\s (signal term-flush))) (condition-case nil (while t (sit-for 100)) (term-flush (set-window-configuration conf)))) Then some of these use-case concerns could be mooted altogether. Lynn --0000000000003491200637731e85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 13, 2025, 2:26=E2=80=AFAM Eli Zaretskii <eliz@gnu.org= > wrote:
= > From: Daniel Colascione <dancol@dancol.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,=C2=A0 monnier@iro.umontreal.ca,
>=C2=A0 =C2=A078737@debbugs.gnu.org
> Date: Thu, 12 Jun 2025 11:48:50 -0700
>
> Pip Cet <pipcet@protonmail.com> writes:
>
> > I'd like read-event, when called while inhibit-quit is t, to = report
> > quits by setting quit-flag in addition to returning quit_char: it= 'll
> > simplify the C code, and it would make
> >
> > (while t
> >=C2=A0 =C2=A0(let ((inhibit-quit t))
> >=C2=A0 =C2=A0 =C2=A0(read-event)))
>
> I strongly disagree.=C2=A0 read-event should read an event.
> Setting quit-flag by side effect when it happens to read one key and n= ot
> others makes the interface less regular and understandable.

We should start by agreeing that the capability of interrupting a
running Lisp program is a real need.=C2=A0 Are we in agreement about that?<= br> If not, let's first hear the arguments why not.

If we _are_ in agreement about that, we should discuss how this should
be possible if read-event (and perhaps others?) return C-g instead of
raising quit-flag.=C2=A0 The alternatives mentioned until now are:

=C2=A0. restore the old behavior, whereby C-g interrupts read-event
=C2=A0. have a variable that, if set, will restore the old behavior in
=C2=A0 =C2=A0read-event and other affected primitives, to be interruptible = by a
=C2=A0 =C2=A0single C-g
=C2=A0. make two C-g presses "in quick succession" set quit-flag,= IOW
=C2=A0 =C2=A0"C-g C-g" will have the same effect as C-g previousl= y

Are there other alternatives?

What about keeping a (possibly buffer-local?) = lisp variable holding a list of keystrokes mapped to thunks that are treate= d as generating lisp machine "interrupts"?=C2=A0 The key strokes = would be processed by C machinery and never seen directly by lisp code and = not be considered "events".
Then C-g could= be bound to a thunk signalling quit, and the effect of "inhibit-quit&= quot; achieved by removing C-g from the list in a given dynamic scope.=C2= =A0 Then user code could make other key-strokes "special" without= resorting to read-event.=C2=A0 For example, this read-event call in term.e= l:
(message "Hit space to flush")
=C2=A0 =C2=A0 =C2=A0 (let ((ch (read-event)))
=C2=A0(if (eq ch ?\s)
=C2=A0 =C2=A0 =C2=A0= (set-window-configuration conf)
=C2=A0 =C2=A0(push c= h unread-command-events)))

Could be replaced by something like
(with-interru= pts ((?\s (signal term-flush)))
=C2=A0 (condition-ca= se nil
=C2=A0 =C2=A0 (while t (sit-for 100))
=C2=A0 =C2=A0 =C2=A0(term-flush (set-window-configuration c= onf))))

Then some of the= se use-case concerns could be mooted altogether.
Lynn

--0000000000003491200637731e85-- From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 12:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174981759219891 (code B ref 78737); Fri, 13 Jun 2025 12:27:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 12:26:32 +0000 Received: from localhost ([127.0.0.1]:43949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ3UN-0005Al-JN for submit@debbugs.gnu.org; Fri, 13 Jun 2025 08:26:32 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:50683) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ3UK-0005AV-P0 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 08:26:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749817582; x=1750076782; bh=3nIQ3BAQYkuu2Oo+k69UzwQpyf6nOWnPCZFRoEkDmWw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=jlO/4hzjq4Ty8JVQqe2PNkRIGh8cI95iw/93kTCrgGeiD5+Csfu/ET7sn0ppTVAD8 c/FwPSlsI+GggWNSGEz99AHuaBL4uZcjY3ME+4Fohfool1jh/JGM5TRNpbyC/4fJtw EKp5T+g/QM17qAakZtr3F6x7ksekVjV38NWiXoQtybQWSy4tdez5IQ/ENb7YfLFeQE jzs/943RTAZ6H2v3fbGWC11P/jPEiUIuu5kwbzd79TMeSNwO2vDXj4EPJWmJ5SX4Dg xGrXbCl9ABc1F9aBXf3gAEsuxWrWj8VnFK6fXlC6FoVEd0ZSywlZSQfTf7r5BY3f/u ClrDt7lfopv8g== Date: Fri, 13 Jun 2025 12:26:19 +0000 From: Pip Cet Message-ID: <87v7ozygih.fsf@protonmail.com> In-Reply-To: <86tt4kdw7r.fsf@gnu.org> References: <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86tt4kdw7r.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 73eb4570468fbdb02639bcd444c54364c532a2e7 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Eli Zaretskii" writes: >> Date: Thu, 12 Jun 2025 18:37:58 +0000 >> From: Pip Cet >> Cc: dancol@dancol.org, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >> >> "Eli Zaretskii" writes: >> >> > Please describe the situations where you'd like it to throw to top >> > level and it doesn't now. >> >> One situation for ordinary quits; three for force-quit. >> >> Situation 1: >> >> I'd like read-event, when called while inhibit-quit is t, to report >> quits by setting quit-flag in addition to returning quit_char: it'll >> simplify the C code, and it would make >> >> (while t >> (let ((inhibit-quit t)) >> (read-event))) >> >> quittable, as I naively expected it to be. The old behavior would >> remain available, but require an extra let binding. > > But isn't it confusing that to have something quittable one needs to > bind inhibit-quit non-nil? I'm confused: the code above should be quittable whether or not the "let" line is present, as long as the "let" line comes after the "while" line: we unbind inhibit-quit after each iteration, and I'm expecting Emacs to take this opportunity to quit. I want to expand the number of situations in which a simple C-g quits, and expand the number of situations in which a triple C-g force-quits. (while t (read-event)) is quittable now, and should remain so, IMHO. > The na=C3=AFve expectation from this is that the code affected by > inhibit-quit non-nil is _not_ quittable, no? Indeed, but the code outside of the let, once per loop iteration, should be. >> Note that this isn't >> >> (let ((inhibit-quit t)) >> (while t >> (read-event))) > > Which is also confusing by its inconsistency. In general, the order > of let-bindings doesn't matter. I don't see how it's inconsistent, sorry. If I bind inhibit-quit and keep it bound while clearing quit-flag, I get an unquittable loop. If I repeatedly bind and unbind inhibit-quit so it becomes nil once per iteration, I should get a quit when it does become nil, after the binding has been unwound but before the next iteration's binding goes into effect. >> Situation 3: >> >> Several force-quits in the same session. Reset force_quit_count to 0 >> once it reaches 3. I've seen force_quit_count reach higher values than >> 3 (there was no regular quit in between force quit attempts). > > If you are talking about a GUI session, then IME the 'emergency exit" > procedure isn't reliably working in that case, and I'm not sure the > implementation intends to support that. I always knew that it's only > reliably working on TTY frames. I'm talking about the GUI case, yes. It seems like an oversight to me. Two successive emergency quits don't work if both of these conditions hold: 1. there's no intervening regular C-g 2. quit-flag is non-nil So a recipe would be: (let ((inhibit-quit t)) (setq quit-flag t) (while t)) C-x C-e C-g C-g C-g C-x C-e C-g C-g C-g Expected outcome: two emergency quits Actual outcome: one emergency quit, no further emergency quits possible. > Or are you talking about the effect of the changes on the branch? I'm not, no. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 13:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498217705340 (code B ref 78737); Fri, 13 Jun 2025 13:37:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 13:36:10 +0000 Received: from localhost ([127.0.0.1]:45038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ4Ze-0001Mi-1E for submit@debbugs.gnu.org; Fri, 13 Jun 2025 09:36:09 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:50064) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ4ZZ-0001MS-QD for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 09:35:59 -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=PRNxH1JZjU/1LBxn7MfT8zWXOobuGCeVcsvzOZ+x14Q=; b=galhTUOi3mvr/7g3aaS28lvNv4 49G+r1wBQj5irYlgzX4ufabmGC37BessqfEi0RqIvNAIoeVWmGxAkttn0gp3otDcnWGHduPBeyReO 5Puybq8l4Sd62HvD6NgXwzbxXji6FO/o2hHfdClaOpIbsmKLTeQg+Oa6clxZhkryV2v1I+5Kmy97w fYHLF7QdLT1sYt/6BDghqfYLq3kX//tJ9XFOqMNdl+R4ty5zWNZoBYEsO/Nkhut9P2IBbo2mePjWN M9eYo+lWSm+KN2C9q6vP7lXvoO0UvbEpenp0KtDLvF5hC+R1ZOb7Y6O72jxOBvzczidaF8zDdGwBe E2NyuRxQ==; Received: from [2600:1010:b047:2f06:0:48:6379:f01] (port=40836 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 1uQ4Y1-00BtaH-2z; Fri, 13 Jun 2025 09:34:22 -0400 Date: Fri, 13 Jun 2025 06:35:40 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <86frg3euz5.fsf@gnu.org> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86frg3euz5.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-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 June 13, 2025 4:34:06 AM PDT, Eli Zaretskii wrote: >> From: Daniel Colascione >> Cc: pipcet@protonmail=2Ecom, monnier@iro=2Eumontreal=2Eca, 78737@debb= ugs=2Egnu=2Eorg >> Date: Fri, 13 Jun 2025 00:28:45 -0700 >>=20 >> Eli Zaretskii writes: >>=20 >> >> From: Daniel Colascione >> >> Cc: Eli Zaretskii , monnier@iro=2Eumontreal=2Eca, >> >> 78737@debbugs=2Egnu=2Eorg >> >> Date: Thu, 12 Jun 2025 11:48:50 -0700 >> >>=20 >> >> Pip Cet writes: >> >>=20 >> >> > I'd like read-event, when called while inhibit-quit is t, to repor= t >> >> > quits by setting quit-flag in addition to returning quit_char: it'= ll >> >> > simplify the C code, and it would make >> >> > >> >> > (while t >> >> > (let ((inhibit-quit t)) >> >> > (read-event))) >> >>=20 >> >> I strongly disagree=2E read-event should read an event=2E >> >> Setting quit-flag by side effect when it happens to read one key and= not >> >> others makes the interface less regular and understandable=2E >> > >> > We should start by agreeing that the capability of interrupting a >> > running Lisp program is a real need=2E Are we in agreement about tha= t? >> > If not, let's first hear the arguments why not=2E >>=20 >> Which Lisp programs? > >All of them=2E Do you want a mechanism that can interrupt all Lisp programs or not? I hav= e such a mechanism=2E >> One that calls (while t (read-event))? One that >> calls (let ((inhibit-quit t)) (while t (read-event))? How about one >> that calls (while t (read-key-sequence ""))? How about one that calls >> (let ((inhibit-quit t)) (while t (read-key-sequence ""))? If you adopt >> the tenet that Lisp programs always be uninterruptible, _something_ has >> to change from the present, because 3/4 of my examples above cannot >> be quit=2E > >So because we currently cannot interrupt some programs we should give >up the ability to interrupt all of them? My proposal allows us to interrupt all Lisp programs=2E I don't know how m= any times I have to say this to get the point across=2E > Please be serious=2E Please engage with what I'm saying and at least try to say things that mak= e internal sense=2E >Arguments like the above are a red herring, and don't help advancing >this discussion towards some kind of agreement=2E You just said above that we should consider the interruptabiltity of all L= isp programs=2E I cited examples of Lisp programs=2E That means these Lisp = programs are relevant to the conversation, as they, being Lisp programs, be= long to the category of all Lisp programs=2E >Do you want the branch merged at some point?=20 Do you want bugs fixed and behaviors improved at some point? > Then please drop the >attitude and start participating in the discussion seriously=2E You >understand very well what I meant above, even though it is somewhat >vague=2E=20 Actually, I have no idea what you mean: you say things like you're not sur= e whether we can distinguish two C-g presses from a double C-g press=2E The= re are the same thing=2E It's like asking whether we can distinguish #00f f= rom #0000ff=2E > We all know what Emacs can and cannot do today, so I allow >myself not to write too many well-known details=2E > >Let's consider the current capabilities of interrupting Lisp programs >as base line, and try to maintain that base line, if not improve on >it=2E Okay? =20 I'm suggesting being able to interrupt all Lisp programs=2E Not all Lisp p= rograms can be interrupted today=2E I have explained in multiple places how= that is to be done=2E I am happy to explain further if you give me some su= bstantial technical questions about the mechanisms involved=2E When Lisp writes (while t (some-event-reading-function)), programmer inten= t is not clear=2E It's not clear because C-g is overloaded and can be eithe= r an event or a quit command=2E On the one hand, the Lisp is running Lisp a= nd we have a general contract that Lisp can be interrupted with C-g=2E On t= he other hand, Lisp is asking to read an event, and C-g can be an event=2E = We have to resolve the ambiguity SOMEHOW=2E Right now, Emacs resolves the a= mbiguity in an inconsistent and ad-hoc manner=2E If the some-event-reading-= function above is read-event, we resolve the ambiguity in favor of quitting= =2E If instead some-event-reading-function is read-key-sequence, we resolve= the ambiguity in favor of event reading=2E This inconsistency is real, con= fusing, and illogical=2E In my proposal, we resolve the ambiguity in favor = of event reading and use multiple C-g presses to indicate user intent to qu= it instead of provide input=2E I don't believe there's a practical, real wo= rld use case in which a single C-g will be insufficient, but the ability to= press C-g multiple times will be there regardless=2E If you'd like to conf= igure your Emacs to resolve the ambiguity in favor of quitting, you can do = that by changing one variable=2E Either way, behavior will be consistent am= ong all Lisp functions that read events=2E Would you please engage substantively with the previous paragraph instead = of calling it a distraction and then raising points germane to exactly what= the previous paragraph covers? Again, nobody is talking about making users count C-g=2E Nobody is talking= about requiring multiple C-g presses in any real world case=2E The change = I'm talking about will make Emacs more consistent, and I've yet to see anyt= hing in the real world it would break=2E My change also makes Emacs safer, because in my model, you *can* break out= of (while t (read-key-sequence)) and in master today you cannot=2E There w= ill be *one* uniform and consistent (and easy to understand) model for how = we address the *inherent* ambiguity about what control-g on a keyboard mean= s=2E Or does it still not satisfy your intentionally-pedantic >interpretation of what I write? I wouldn't have to be pedantic if you would be clear about what you want= =2E >> > If we _are_ in agreement about that, should discuss how this should >> > be possible if read-event (and perhaps others?) return C-g instead of >> > raising quit-flag=2E The alternatives mentioned until now are: >> > >> > =2E restore the old behavior, whereby C-g interrupts read-event >>=20 >> Does not satisfy the "lisp programs always be >> interruptible" requirement=2E >>=20 >> > =2E have a variable that, if set, will restore the old behavior in >>=20 >> Same as above=2E >>=20 >> > read-event and other affected primitives, to be interruptible by a >> > single C-g >>=20 >> Same as above=2E > >Please reconsider your responses with a more serious and cooperative >attitude=2E Then make some sense=2E You talk about requirements=2E I explain how we me= et those requirements=2E That's pedantry? >> > =2E make two C-g presses "in quick succession" set quit-flag, IOW >> > "C-g C-g" will have the same effect as C-g previously >>=20 >> Only for read-event=2E > >Why "only"? > >Having the behavior vary depending on whether the program does or >doesn't call read-event will bring inconsistency, something we want to >avoid (and which I think you argued against)=2E It is logically impossible to combine two things: 1) all Lisp programs can be interrupted with a single C-g 2) a Lisp program can read a C-g as an event=2E This isn't pedantry=2E It's foundational logic=2E Demanding a solution tha= t satisfies both constraints is impossible=2E It would require reading the = user's mind=2E >> If you want to adopt a principled stance that every Lisp program be >> interruptible, you necessarily, as a matter of logic, regard multiple >> behaviors of current Emacs to be bugs worth fixing=2E > >Not useful=2E I didn't mean that, and you know it=2E You just said at the start of this email that you're considering the inter= ruptabiltity of all Lisp programs=2E I have a scheme to make all of them in= terruptible=2E Nobody else has proposed one=2E >> > Are there other alternatives? >>=20 >> Get in a time machine, go back 40 years and stop overloading C-g? > >Even less useful=2E Again, do you want this branch to be merged any >time soon? Because I'm this close to losing my patience=2E Life's too >short to waste it on "arguments" such as this one=2E > And I'm losing patience with objections that contradict themselves and fai= l to address my points=2E >> > I don't think there's disagreement on that level=2E So let's drop th= is >> > kind of arguments, because they are not useful for this discussion=2E >> > The problem we face is how to allow Lisp code to be quittable=2E A L= isp >> > program that calls read-event is not different from a Lisp program >> > calling any other function, so we still need such programs to be >> > quittable somehow=2E Let's discuss how best to do it, okay? >>=20 >> Yes or no: should (while t (read-key-sequence)) be quittable? > >Why is that relevant? If you'd like to cooperate seriously, I'm happy to do so provided you do s= o as well, and part serious cooperation is answering clarifying technical q= uestions instead of questioning their relevance=2E So, yes or no? > I asked about read-event, not >read-key-sequence=2E Can we first discuss the read-event case? Once we >are done with that, we can move to other cases=2E You just said above you want to consider the interruptabiltity of all Lisp= programs=2E Now you're calling the interruptabiltity of some Lisp programs= irrelevant=2E Which is it? It's important to consider the input model as a whole=2E I don't think we = can get to a good place by focusing on one function at a time and be wilful= ly oblivious about whether different functions together form a coherent who= le=2E >> If yes, maintaining today's behavior isn't an option=2E There are plen= ty >> of other Lisp programs that cannot be quit --- even (let ((inhibit-quit >> t)) (while t)) cannot be quit! > >If inhibit-quit is bound to a non-nil value, the program cannot be >quit, and that's a feature=2E This seems like both a contradiction and poor UX: you want some Lisp progr= ams to be interruptible and others not=2E Why is it a feature that some Lis= p programs cannot be quit? I thought you wanted to talk about all Lisp prog= rams being quittable=2E Why is it desirable that Emacs be left in an unreco= verable state? In my proposal, users will be able to interrupt *any* program of the form = (let ((inhibit-quit t)) (while t (anything))) by pressing C-g enough times = to override the inhibit-quit=2E Emacs already provides this feature, but on= ly (AFAICT) on primary TTYs=2E =20 If this ability to break out of a loop wrapped in inhibit-quit is bad, sho= uld we remove the existing force-quit feature? Yes or no, please=2E My proposal is a generalization of a feature we've had for decades=2E It i= s not a brand new concept=2E Is it a bug to allow these programs to be interrupted? Yes or no=2E If yes= , why isn't the existing force quit feature being removed? If not, why is b= eing unable to quit some Lisp programs a "feature"? You say I know what you mean=2E I'm really not sure I do, because from whe= re I'm sitting, you're not answering questions that would resolve the contr= adictions in what you're saying=2E > Why are we discussing this? Because we're talking about interrupting Lisp programs=2E That's the subje= ct of the whole conversation=2E > >> If no, what is the problem with cleaning up Emacs by regularizing how w= e >> treat C-g as an event versus some kind of longjmp? > >Again, let's discuss the read-key-sequence case after we are done with >the read-event case=2E How can we consider what to do with read-event without thinking about how = it fits into the broader picture? >> >> > Several force-quits in the same session=2E Reset force_quit_count= to 0 >> >> > once it reaches 3=2E I've seen force_quit_count reach higher valu= es than >> >> > 3 (there was no regular quit in between force quit attempts)=2E >> >>=20 >> >> Get rid of force_quit_count entirely and just detect (by writing int= o a >> >> ring buffer) whether we've received N quits in the last T millisecon= ds=2E >> >> That'll work the same way regardless of how quits gets detected=2E = We can >> >> change N and T freely=2E >> > >> > This is the last alternative I described above=2E It is IMO less >> > desirable, because it is not always easy to press C-g twice quickly, >> > for whatever reasons=2E It is even less desirable to define "quick >> > succession" in terms of time, because timings can differ a lot >> > depending on the free computing resources and the CPU power in >> > general, so determining the best default values will be very >> > challenging, to say the least=2E >>=20 >> I don't see the ambiguity being a realistic problem=2E How often do yo= u >> press C-g three times while a single command is running? > >I usually expect a single C-g to quit=2E If it doesn't help, I can >press C-g several times, I'm not sure I count them=2E In my proposal, on every real world case, C-g returns you to the command l= oop when you want to go there and lets Lisp read C-g as an event when you w= ant to do that=2E You can construct buggy or pathologically written program= s that you can't exit with a single C-g because the meaning of that keystro= ke is overloaded=2E You can still get back to the main loop in these rare c= ases by pressing C-g repeatedly=2E You don't have to count them=2E You just= keep pressing C-g until you are back in the command loop, just like today'= s force quit feature=2E >> We're not talking about, say, six times in multiple rounds of M-x this, >> select that, deactivate mark over here=2E Those are multiple commands= =2E >> In between multiple commands, a C-g will cause a keyboard-quit and >> you'll regain control over Emacs=2E I'm asking, during _one_ command, = how >> many times you typically press C-g and _don't_ mean it as a quit=2E > >See above=2E > >> We already have a force quit mechanism that kicks in at N=3D3=2E How o= ften >> do you activate it? > >I never saw it at work, except on TTY frames=2E=20 We can make it work everywhere=2E Is that not an improvement? > But then Windows >doesn't have SIGIO, it emulates that=2E Maybe that's the reason=2E SIGIO isn't the reason=2E The reason force quit doesn't work is the way it= 's implemented=2E We can implement it better=2E That's my proposal, if you'= d like to consider it in more detail=2E >> >> On your Emacs, you can set N to one and T to zero=2E >> > >> > If read-event still returns a keyboard input event when C-g is >> > pressed, I don't see how N =3D 1 would work=2E Can you describe how = it >> > would work? >>=20 >> It wouldn't=2E Such a setting would prevent read-input returning C-g= =2E >> That shouldn't be the default=2E > >Sorry, I don't understand=2E If N =3D 1, what will read-event do when th= e >user presses C-g while inside read-event? =20 If N=3D1, it will quit after a single C-g=2E Specifically, it will raise a= quit signal=2E It will raise this signal instead of returning normally=2E = It will not return it as C-g to Lisp=2E If N=3D1, all the Lisp level input = reading functions, including read-key-sequence, will interpret a single C-g= as quit=2E > Will it return the input >event C-g, or will it quit? I thought your changes make read-event >always return the input event, was I mistaken? You're asking about the N=3D1 case=2E I'm not proposing that N=3D1 be the= default=2E For all values of 1 <=3D N <=3D M, I'm specifically proposing: When inhibit-quit is nil: #quits in [1,N-1]: event reading functions interpret C-g as an event calle= d \?C-g, aka the number 7=2E They return this event without quit-flag set= =2E #quits in [N, infinity): event reading functions interpret C-g as a quit= =2E They do not return=2E They end by calling Fsignal with quit error symbo= l=2E When inhibit-quit is non-nil: #quits in [1,N-1]: same as above=20 #quits in [N,M-1]: return \?C-g with quit-flag set #quits in [M, anything): exit nonlocality by calling Fsignal with quit err= or signal, effectively ignoring inhibit-quit=2E Print a message saying we'v= e done so=2E If debug-on-quit is set, we enter the debugger when the above table says t= he word "Fsignal"=2E If throw-on-input, we raise quit on any input event whatsoever, never retu= rning to Lisp, no matter the value of #quits, N, or M=2E My proposal, by the way, does not change the meaning of quit-flag=2E If you find the above proposal unacceptable, can you please point to a spe= cific behavior it encodes and talk about what you'd rather it do differentl= y? Assume we can reliably detect #quits, please=2E I'm happy to talk about *h= ow* we detect repeated C-g, but the mechanism by which we do is independent= of rhe policy we want=2E >> >> We can customize thresholds for general behavior, but I don't think = we >> >> should not have preferences that alter the operation of fundamental >> >> Emacs primitives=2E You couldn't add a preference that made if rega= rd 0 >> >> as well as nil as false, would you?=20 >> > >> > Why not? If it helps debugging, we could definitely do that=2E=20 In the exceedingly rare case that it is important to allow one C-g instead= of C-g C-g C-g to break out of an read-event or read-key-sequence loop (an= d I have never seen one not deliberately constructed) users can customize N= to be one=2E I anticipate exactly zero people going that, but if you want = the knob, we have it=2E > We >> > already have --enable-checking, which changes how some primitives >> > work, in a very real sense=2E =20 I'm not aware of any interface contracts that checking changes=2E What mig= ht those be? > As long as the feature is for debugging >> > Emacs, anything useful goes, IMO=2E >>=20 >> Because when you add a user option, people expect code you write to >> operate under any value of that option, increasing implementation >> complexity because you have to account for the _possibility_ someone >> might operate in a certain way=2E > >No, people need not expect the code to operate the same under those >special debugging-oriented values=2E We already have such features: >debug-on-error =3D t might well cause some command cease working >normally, and similarly condition-case-unless-debug Because I don't think this debugging mode is needed in any real world scen= ario=2E Nobody I've seen infloops on read event outside a specially crafted= scenario=2E But if you want the knob to enable it, the knob is there in my proposal=2E= Set N=3D1=2E If you set N=3D1, then *both* read-event and read-key-sequenc= e will quit the first time you press C-g=20 >So I think you are bothered by a problem that doesn't need to be >solved=2E > >> >> >>> Maybe a compromise would be to continue the arms race and downgr= ade C-g >> >> >>> to normal input, C-g C-g C-g to a quit, and require even more C-= g's for >> >> >>> a force-quit? >> >> >> >> >> >> That's also possible, though less desirable: counting C-g presses= when >> >> >> you are desperate is not easy and we cannot rely on users to do t= hat >> >> >> reliably=2E >> >> > >> >> > And we'd need a way to detect when a quit is handled (however we d= efine >> >> > "handled") so we could reset force_quit_counter=2E Not a trivial = change=2E >> >>=20 >> >> You don't=2E You just upgrade any quit that happens under the N and= T >> >> threshold above=2E >> > >> > I'm skeptical that we will be able to count C-g presses so as to >> > reliably differentiate between double or triple press and two or thre= e >> > separate C-g presses=2E >>=20 >> There is logically no difference between these two concepts=2E A doubl= e >> keypress *is* two keypresses in a certain window of time=2E What other >> concept could the combination of the words "double" and "press" convey? > >I don't understand what you are saying here=2E Yes, there's no logical >difference between these, which is why I'm saying that reliably >detecting "double C-g" is a challenge=2E We already have that with >double-mouse=2E The difference between double-mouse and "double C-g" is >that with the latter you cannot afford low reliability: when you want >to quit, you want to do it immediately, because the runaway operation >you want to interrupt could be harmful=2E I'm honestly not sure what reliability problems you're talking about=2E We= count the C-g key presses since we last entered the command loop and since= T milliseconds ago=2E If you say T to be a month and N=3D2 then if you're = in a read-event or read-key-sequence loop, press C-g once, suspend your com= puter for a day, and press C-g again, we'll interpret the second C-g as a q= uit and break out of the loop=2E Can you please give me some specific and concrete scenarios you have in mi= nd that might clarify these reliability issues you're talking about? >> > Different machines and OSes, and different >> > system loads, can make it nigh impossible to do reliably=2E And that= 's >> > _bad_, because when I want something interrupted right away, I don't >> > want or even cannot try again and again and again until it works=2E >>=20 >> Then define a separate key that means _only_ quit and that cannot be >> bound to a regular command=2E C-g can't be that command without breaki= ng >> existing code=2E > >It's too late to define a separate key _instead_ of C-g=2E We could >define a separate key _in_addition_ to C-g, but that doesn't solve the >problem: people have C-g hardwired into their muscle memory, and it >will take a lot of time for them to re-learn=2E Meanwhile, we get bug >reports about C-g not working like it did before=2E No, we didn't get a bug report=2E We got a specially constructed program t= hat exercised a beneficial behavior change and called it a bug=2E I've yet = to see a real world problem=2E The person who constructed that program comp= lained that a loop that could be quit before was unquittable now=2E I am tr= ying to explain that it will, in fact, be quittable=2E >So minimizing the behavior changes is still a requirement, even if we >add another key=2E And that's before we even consider what other key >could serve that purpose, which is not a trivial problem to solve >portably I'm not talking about adding another quit key=2E That's not the right solu= tion=2E I don't see a real world scenario in which multiple C-g doesn't wor= k well enough, and we have, what, decades of experience with this mechanism= on TTYs? Why is taking the force quit mechanism, fixing its reliability is= sues, and generalizing it to GUIs suddenly a problem? >> Treating repeated C-g presses made in a reasonable window of time withi= n >> the scope of a single command in such a way that we're almost certainly >> not confusing this series of keystrokes with C-g-as-command input solve= s >> the problem=2E > >That's possible, but it is not the best alternative IMO, for the >reasons I explained=2E I've yet to see you propose a different solution=2E All I've seen is resis= tance to change whether it's beneficial or not=2E My proposal allows you to interrupt any Lisp program=2E In every real worl= d scenario, you can interrupt with one C-g=2E In pathological cases, you ca= n interrupt by pressing C-g multiple times=2E This mechanism is reliable=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 13:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lynn Winebarger , Eli Zaretskii Cc: 78737@debbugs.gnu.org, Pip Cet , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498221867169 (code B ref 78737); Fri, 13 Jun 2025 13:44:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 13:43:06 +0000 Received: from localhost ([127.0.0.1]:45216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ4gU-0001rX-0V for submit@debbugs.gnu.org; Fri, 13 Jun 2025 09:43:06 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:41006) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ4gP-0001qW-R7 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 09:43:04 -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=X7cVhm9kdHOrck2pNk+4uoUzgNtBY080T/KGnJPwah8=; b=BoS+sYCLqFFfPWA1M3dFrj7tOq M4LVqypN6NV7jVYp+wcHidPs0VfiUJoA6cZC9Cf8EU2hGa85TPza2J1KLFg/VVsfPWk2o8QzPvrqr gVyhHRiEtkJApKchopwzHont+kdKOScbqebfUPrV1FF8tkpTJ+1GAMBkUpopf6/xftP79ZnqmPo8T 2nbZORcG7PNLKkGUO/sd+/zWrXh433JvSErXy6Kzbr9IT89fTEmyTRW0/9MfNB5WVurgmGeseEmfk SGjO2eTyC8fTstt0DtglZd5feUNSKw9kR6Inan94KCq2yaFl+H5EslB+WKwxQ4+K1qghoSk0ok0NC Z7c+zGyg==; Received: from [2600:1010:b047:2f06:0:48:6379:f01] (port=55578 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 1uQ4f3-00BtcX-1Y; Fri, 13 Jun 2025 09:41:37 -0400 Date: Fri, 13 Jun 2025 06:42:58 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> Message-ID: <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 13, 2025 5:23:34 AM PDT, Lynn Winebarger wr= ote: >On Fri, Jun 13, 2025, 2:26=E2=80=AFAM Eli Zaretskii wrot= e: > >> > From: Daniel Colascione >> > Cc: Eli Zaretskii , monnier@iro=2Eumontreal=2Eca, >> > 78737@debbugs=2Egnu=2Eorg >> > Date: Thu, 12 Jun 2025 11:48:50 -0700 >> > >> > Pip Cet writes: >> > >> > > I'd like read-event, when called while inhibit-quit is t, to report >> > > quits by setting quit-flag in addition to returning quit_char: it'l= l >> > > simplify the C code, and it would make >> > > >> > > (while t >> > > (let ((inhibit-quit t)) >> > > (read-event))) >> > >> > I strongly disagree=2E read-event should read an event=2E >> > Setting quit-flag by side effect when it happens to read one key and = not >> > others makes the interface less regular and understandable=2E >> >> We should start by agreeing that the capability of interrupting a >> running Lisp program is a real need=2E Are we in agreement about that? >> If not, let's first hear the arguments why not=2E >> >> If we _are_ in agreement about that, we should discuss how this should >> be possible if read-event (and perhaps others?) return C-g instead of >> raising quit-flag=2E The alternatives mentioned until now are: >> >> =2E restore the old behavior, whereby C-g interrupts read-event >> =2E have a variable that, if set, will restore the old behavior in >> read-event and other affected primitives, to be interruptible by a >> single C-g >> =2E make two C-g presses "in quick succession" set quit-flag, IOW >> "C-g C-g" will have the same effect as C-g previously >> >> Are there other alternatives? >> > >What about keeping a (possibly buffer-local?) lisp variable holding a lis= t >of keystrokes mapped to thunks that are treated as generating lisp machin= e >"interrupts"? The key strokes would be processed by C machinery and neve= r >seen directly by lisp code and not be considered "events"=2E >Then C-g could be bound to a thunk signalling quit, and the effect of >"inhibit-quit" achieved by removing C-g from the list in a given dynamic >scope=2E Then user code could make other key-strokes "special" without >resorting to read-event=2E For example, this read-event call in term=2Ee= l: >(message "Hit space to flush") > (let ((ch (read-event))) > (if (eq ch ?\s) > (set-window-configuration conf) > (push ch unread-command-events))) > >Could be replaced by something like >(with-interrupts ((?\s (signal term-flush))) > (condition-case nil > (while t (sit-for 100)) > (term-flush (set-window-configuration conf)))) > >Then some of these use-case concerns could be mooted altogether=2E We already have something like that=2E :-) read-event already runs the eve= nts it reads through special-event-map, right? We don't even need to create= a separate thunk list concept: we could just bind C-g in special event map= and do what we want, right? The only special thing about C-g is how we treat it when Lisp is running= =2E When it's instead reading an event, it can and be a boring event proces= sed the same way every other event is=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Pip Cet , Lynn Winebarger , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982327413017 (code B ref 78737); Fri, 13 Jun 2025 14:02:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:01:14 +0000 Received: from localhost ([127.0.0.1]:46578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ4y2-0003Ns-8y for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:01:14 -0400 Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:46517) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQ4xz-0003NN-2L for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:01:11 -0400 Received: by mail-wr1-x433.google.com with SMTP id ffacd0b85a97d-3a50956e5d3so1771625f8f.1 for <78737@debbugs.gnu.org>; Fri, 13 Jun 2025 07:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749823265; x=1750428065; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=uknMCewtSSvr1YG6t8Yq2AJNYk0lNYF+Hm7C+LUwBdg=; b=gOTvLBZ8T7NzUN5FiC3rb/mqNu72MNLZufApp4uh9OxvaiqaqL7FiYpN1znovV6UoH zlv3OI9TS2y0rOJPyIjVrBaXLT+lOxH53oA7/TNRrSm62fQIptgDCg16gLHSuLZriD58 QNyyFcWgyowPVx5zw3pirbimENFJuDp0p3cKXGT7Yj18ijmpWCN6m/1IhgEfaParLpNL 59594COqdjF7SFk6RaFVt38NuyjxtG/LqeMvzbKFLyaJ36I38U1R9peZl2vSXBaA3Ww1 msieCPi5csdApTynPgcPZ/NVcO2KMXBAH5NnxsTape34IBlJ7f8HCnLFK04zirmceOq7 BFVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749823265; x=1750428065; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=uknMCewtSSvr1YG6t8Yq2AJNYk0lNYF+Hm7C+LUwBdg=; b=l8M3mt17CfSqQ7952q8bRY1GGeV8ts8iyD4JmhlPmlFa4OvIQuiXPpnbEOSJ5X54T/ /Q5Dt2IMStt7vwCkBi4af3wJCys4U/SKE4va1xePvEB1YVsgM84JDUjreyDTe3hNIypm f6/kyzCW1xTxjyLmQzC3M2ZKAsvU0TwwH496CD6lSYggcu1kiv4m7nDoWipixl2w5pwV hDf1ahKOysNyOOTNntW/XC6+HkiBVd+mCAR8PVnnay5Q8MTKiqnOZurDSdYN/+DxnLwn 1CeaiybPamCZJe+OJPowfzdhF8NKkEdYSahl7FGXTHOCS2yg9INhyhlqJEuzr2Uepe8e /xGQ== X-Forwarded-Encrypted: i=1; AJvYcCWUCq6qgErNn3tDxatHBZX4aay0oT/2suvGq0PbZyopTbRWrbc5GJ2cUajp5tf9rj3KBchnlQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwA0N/9v76zWH93EKO95i4uNkJjirrohfc30mys3rsQDpl+bgf+ MZnKBlyBVSnkeCSgk/TfFoB8/P+TOAk0gRYzjSrZ8QNOfXT2A4LTiSaH X-Gm-Gg: ASbGncudESMS//CEafZkwOUn5jNO06Wu4ZYN8uE5Uddnkh9vdOzr7ohsb8G05VxmNhR 3d+1WrXu7X0LemyqTLjMKxk6CySmxe6AyMg1R/hz7RDbkhYjGGIq8zpcAegV8YHjiSs+H1HFqyv Sc5BlY/gKuuHoZX20nIAi+bkzp+LkTFywNuSpsAEJ3ktw8PNNEmXIlE9ZPe3hqI+d1kOdISzB62 pcZGkDe+jm42YlV+4sB134koHGJ3QTfYux58GAbEsLlbNz09iJd3LElauCswUDheujM4MDjhmhj 0MGmZ0Q1cDzwZt9TtMVWzfMr0wrKOhgXO48x6rhTZeJ/V1eNIuld5+5MVns4Vppfbu+i3lZmMEB s9Ih5T9PDOQn0/Uplil9sCMrrjxdt2XRGzv8kKQDTro3zTBQOSohjgPyJiiBcI4mffA== X-Google-Smtp-Source: AGHT+IFruJYyIfdxPyvCnrdiTYdagg/MQ8js44QAaZu8/v73T7V5gQHkgEvoeyoyVxVdZ99osBYBIA== X-Received: by 2002:a05:6000:310e:b0:3a5:52d4:5b39 with SMTP id ffacd0b85a97d-3a5686831camr2860779f8f.8.1749823263038; Fri, 13 Jun 2025 07:01:03 -0700 (PDT) Received: from pro2 (p200300e0b704ee00104b88b47a1a54cc.dip0.t-ipconnect.de. [2003:e0:b704:ee00:104b:88b4:7a1a:54cc]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4532e232e4asm52726235e9.11.2025.06.13.07.01.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Jun 2025 07:01:02 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> Date: Fri, 13 Jun 2025 16:01:01 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) 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 (-) Daniel Colascione writes: > We already have something like that. :-) read-event already runs the > events it reads through special-event-map, right? Entirely unrelated, I just came across this because I searched for read-event. Let me just mention that read-event does not respect input-decode-map. This is a problem on ttys, see bug#75886. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lynn Winebarger , Eli Zaretskii Cc: 78737@debbugs.gnu.org, Pip Cet , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982334613134 (code B ref 78737); Fri, 13 Jun 2025 14:03:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:02:26 +0000 Received: from localhost ([127.0.0.1]:46582 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ4zB-0003Pl-Pr for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:02:26 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:45752) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ4z8-0003Pb-CP for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:02:24 -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=VmlBO/dSRliHfgeEjg15LK6Wo3Z5s3pmoh2GgMQkL0I=; b=J6vfShQV5ImUF7MD9wO8aDOTh/ dFCPQem4D6hs7d5LyCOhjpo02IrFBVALodRoXvbbgS8wuNqyXde5mXZx1ieKeuGU/8sqJnOvFi2ig nMfS0y+bYuaPvxHr50kRekdAGmi/raLXMLyox9/Ve/U6Y1rkQAuRvuDoo1uNv32nDtOxO0U14fP5H XHMCpobvRNBwa68Jl9TowKChuP3GkRGFHMMbQFgD/pNIuwumnwW4NdxV7xPq4HbzSTG6AcztY6E3f ez9+aZhBn8L1GlqyeaTIGmLfN/ut2/9fdjk1rTwIq/gq1ICHii91hJvQi8WBfkK8mM07/qUEVhZn2 H1aHB6Vw==; Received: from [2600:1010:b047:2f06:0:48:6379:f01] (port=59802 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 1uQ4xm-00Btfo-0c; Fri, 13 Jun 2025 10:00:58 -0400 Date: Fri, 13 Jun 2025 07:02:14 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> Message-ID: <37BCCFA8-8EFC-4BB1-8B4F-D805FB7E1B6A@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 13, 2025 6:42:58 AM PDT, Daniel Colascione w= rote: > > >On June 13, 2025 5:23:34 AM PDT, Lynn Winebarger w= rote: >>On Fri, Jun 13, 2025, 2:26=E2=80=AFAM Eli Zaretskii wro= te: >> >>> > From: Daniel Colascione >>> > Cc: Eli Zaretskii , monnier@iro=2Eumontreal=2Eca, >>> > 78737@debbugs=2Egnu=2Eorg >>> > Date: Thu, 12 Jun 2025 11:48:50 -0700 >>> > >>> > Pip Cet writes: >>> > >>> > > I'd like read-event, when called while inhibit-quit is t, to repor= t >>> > > quits by setting quit-flag in addition to returning quit_char: it'= ll >>> > > simplify the C code, and it would make >>> > > >>> > > (while t >>> > > (let ((inhibit-quit t)) >>> > > (read-event))) >>> > >>> > I strongly disagree=2E read-event should read an event=2E >>> > Setting quit-flag by side effect when it happens to read one key and= not >>> > others makes the interface less regular and understandable=2E >>> >>> We should start by agreeing that the capability of interrupting a >>> running Lisp program is a real need=2E Are we in agreement about that= ? >>> If not, let's first hear the arguments why not=2E >>> >>> If we _are_ in agreement about that, we should discuss how this should >>> be possible if read-event (and perhaps others?) return C-g instead of >>> raising quit-flag=2E The alternatives mentioned until now are: >>> >>> =2E restore the old behavior, whereby C-g interrupts read-event >>> =2E have a variable that, if set, will restore the old behavior in >>> read-event and other affected primitives, to be interruptible by a >>> single C-g >>> =2E make two C-g presses "in quick succession" set quit-flag, IOW >>> "C-g C-g" will have the same effect as C-g previously >>> >>> Are there other alternatives? >>> >> >>What about keeping a (possibly buffer-local?) lisp variable holding a li= st >>of keystrokes mapped to thunks that are treated as generating lisp machi= ne >>"interrupts"? The key strokes would be processed by C machinery and nev= er >>seen directly by lisp code and not be considered "events"=2E >>Then C-g could be bound to a thunk signalling quit, and the effect of >>"inhibit-quit" achieved by removing C-g from the list in a given dynamic >>scope=2E Then user code could make other key-strokes "special" without >>resorting to read-event=2E For example, this read-event call in term=2E= el: >>(message "Hit space to flush") >> (let ((ch (read-event))) >> (if (eq ch ?\s) >> (set-window-configuration conf) >> (push ch unread-command-events))) >> >>Could be replaced by something like >>(with-interrupts ((?\s (signal term-flush))) >> (condition-case nil >> (while t (sit-for 100)) >> (term-flush (set-window-configuration conf)))) >> >>Then some of these use-case concerns could be mooted altogether=2E > >We already have something like that=2E :-) read-event already runs the ev= ents it reads through special-event-map, right? We don't even need to creat= e a separate thunk list concept: we could just bind C-g in special event ma= p and do what we want, right? > >The only special thing about C-g is how we treat it when Lisp is running= =2E When it's instead reading an event, it can and be a boring event proces= sed the same way every other event is=2E Oh yeah, one thing I forgot to mention: for the *asynchronous* case, the C= code is pretty deeply coupled to quit_char, and IIRC, even hard codes 7, C= -g, in some places instead of quit_char=2E In your proposal, we'd reference= s to quit_char and literal 7 to calls to a new bool is_quit_char(int c) fun= ction -- and this function would return true for any raw keys bound in spec= ial-event-map=2E In this way, you'd be able to define as many asynchronous-= input characters as you wanted=2E We wouldn't get the special SIGINT behavior this way (because in termios t= here can be only one interrupt key, right?), but I think that's okay, since= quitting works without the SIGINT wiring and I suspect that we could remov= e the SIGINT wiring and simplify the codebase without losing any actual fun= ctionality=2E=20 From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Pip Cet , Lynn Winebarger , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982398415800 (code B ref 78737); Fri, 13 Jun 2025 14:14:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:13:04 +0000 Received: from localhost ([127.0.0.1]:46760 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ59T-00046k-N5 for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:13:04 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:41400) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ59Q-00046C-Sr for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:13:01 -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=3M0b0gn7oQCEBCF17bb6HGkNezDccWgzNwMPAyPg/Xk=; b=A9Js9KD7NQGAnxVpsoZkX0s0JQ NGOZUW0Jim5mqSzAFr8S6Ifxz5J6D/l9BMevraQBfKME6QCLBc2Z8HosrpdHFERanMvqBnQbIcgvR 4RU78uo5i+mutpDP2dr15THPY93dPJCZ9LiL2yviMH2HfH3zvoc2meCA5XRqLJJfE8ZkziLNBqKV/ 0CoE5TgrQ8RrQ5MmgwcmDndXdxnRcmBt30S7OxigA810YvUCCcUmQYrgG9bmxLpOl+LAUmPdUTaN8 lH79wPbFsqwHaNV+jhrpt2UagCuWO0Cw/Nvs5ih/fPBWadfuN36cwVn7cTiiCkaosXa4p8C99nmzU DdrpEc3w==; Received: from [2600:1010:b047:2f06:0:48:6379:f01] (port=45228 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 1uQ584-00Btiw-1y; Fri, 13 Jun 2025 10:11:36 -0400 Date: Fri, 13 Jun 2025 07:12:56 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> Message-ID: <24B8C58B-D7CE-4596-A685-867B49EE4343@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 13, 2025 7:01:01 AM PDT, "Gerd M=C3=B6llmann" wrote: >Daniel Colascione writes: > >> We already have something like that=2E :-) read-event already runs the >> events it reads through special-event-map, right? > >Entirely unrelated, I just came across this because I searched for >read-event=2E Let me just mention that read-event does not respect >input-decode-map=2E This is a problem on ttys, see bug#75886=2E Seems at least a little related, doesn't it? It's another example of a rea= l world problem caused by inconsistent input reading strategy, isn't it? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982491620524 (code B ref 78737); Fri, 13 Jun 2025 14:29:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:28:36 +0000 Received: from localhost ([127.0.0.1]:47181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5OV-0005Ky-N0 for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:28:36 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29890) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ5OT-0005Kg-Rh for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:28:34 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2D1431002F0; Fri, 13 Jun 2025 10:28:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749824907; bh=Y8b4AzStPkw7H/sQSje9p2XiS6jwIO87V6/1zzs7POk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=KP16sCkIYty0SZR5Vo5ohZlbq09TscbgVshHX8338ZXobuwYQJziGwxhLTzCf2iB6 JK/7YJD6hA6KAg5FJ8UQSsPawVex5qJNvqufFa6Rr7Wra8T6pMhYt7BxVmDvx/UQUN igrCS51lGF7zqzZ2FGjzQa8/hu7YA0Oyz8yryXmKpqksVkco6xeNZyy2yHoYTFsMnK EdmYDlc2zSYElOQwwPVJ/PDRWBrlHXgWGZOEfw9ct/79y30JE4iCfveuwApEy0Qdgv n+1SRJ+2iKlKWP5p92LbAY17Yt3H2CnWYgwtPT/PcGVRD2rgpcHw58dBPTya2RSUTU fdjaoTODlMDIw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id EF073100034; Fri, 13 Jun 2025 10:28:26 -0400 (EDT) Received: from asado (unknown [130.159.220.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A80EE1201A9; Fri, 13 Jun 2025 10:28:25 -0400 (EDT) From: Stefan Monnier In-Reply-To: Message-ID: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> Date: Fri, 13 Jun 2025 10:28:23 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> I like your way of thinking. I'm not completely sure it will solve >> world hunger, and it may come with regressions, but it's worth a try. >> Given the pervasive impact, it might be best to have a global config var >> to enable/disable it (with some scary internal name) until we're >> confident that it's an improvement. > > Check out the branch dancol/quit-improvements2 with a fix for this > problem and multiple others I found along the way. There, we make > read_char report quits as quit_char, protect timer callbacks against > quits properly, inhibit quits in redisplay by default, attempt to quit > more often reading process output, and fix the original > throw-on-input bug. Regarding "inhibit quits in redisplay by default": I've several times got my way out of a jit-lock hang (not necessarily an info-loop, e.g. a nasty regexp explosion) by leaning on `C-g` (the actual behavior sucks, because the quit is caught by the redisplay which then jumps right back into the same jit-lock code, toh apparently there's a bit of progress made along the way, hence the need to lean on `C-g` for a while). Maybe `kill -USR2` would work better? Still, while I agree that we should generally inhibit quits during redisplay, inhibiting all quits is a problem, so I often wish we had two notions of quits: the "normal quit" and the "emergency quit", where the emergency quit puts more emphasis on making sure we stop what we're doing than on preserving a "clean" state (e.g. I don't mind some redisplay glitches after an emergency quit from jit-lock). We'd still want to stay away from core dumps, of course. > (It's dancol/quit-improvements2 not dancol/quit-improvements because I > can't force-push even to a non-mainline branch. Shouldn't we allow > off-mainline force pushes?) Someone mentioned the `scratch/` convention. Note that the repository will still refuse `git push --force`: you need to first delete the old branch with `git push :scratch/foo` and then push the new branch on top. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982543223228 (code B ref 78737); Fri, 13 Jun 2025 14:38:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:37:12 +0000 Received: from localhost ([127.0.0.1]:47401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5Wp-00062Z-Pc for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:37:12 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:45922) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ5Wm-00062P-7o for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:37:09 -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=bffC2qXq2RVFF0nPbl6VYR3RScu3/eE0M3aaAo0L6kU=; b=Kf3JtiXD3oJMjGHxiDn8DqhtrY lwxAoOLUUWtO7V49oTJBeBX1CH7lvuyfB5nKWyVZllM1XWziqPHCHZYgLjUXv7KMuYQOGhRkvEFt9 7ssHeD0YUdvG3TioKt+GgyBuZDZFa4TSr2iKK1T348dyGLBZMfxCrcj4ytPoeJ/c13jQ+bqj0v1t9 j6/ZcEPlimJ2yO0PNpfAWqAFR+XTJd8yD4iFcGyaHQzqbJ40kK5A+l0fGSF8wsXDUM73fgNOQLRyh 5CiVftKZiyiwRveYC2xNSYOx/U1pzqWaTPW4+/frYE0yNa/vABj9c+okayMWnomDGFf8Pi2ggoxCC 323au2/A==; Received: from [164.86.9.12] (port=19570 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 1uQ5VO-00Btnk-0W; Fri, 13 Jun 2025 10:35:43 -0400 Date: Fri, 13 Jun 2025 07:36:57 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> Message-ID: <48D49344-799D-4680-A49C-373282B4F90B@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 13, 2025 7:28:23 AM PDT, Stefan Monnier wrote: >>> I like your way of thinking=2E I'm not completely sure it will solve >>> world hunger, and it may come with regressions, but it's worth a try= =2E >>> Given the pervasive impact, it might be best to have a global config v= ar >>> to enable/disable it (with some scary internal name) until we're >>> confident that it's an improvement=2E >> >> Check out the branch dancol/quit-improvements2 with a fix for this >> problem and multiple others I found along the way=2E There, we make >> read_char report quits as quit_char, protect timer callbacks against >> quits properly, inhibit quits in redisplay by default, attempt to quit >> more often reading process output, and fix the original >> throw-on-input bug=2E > >Regarding "inhibit quits in redisplay by default": I've several times >got my way out of a jit-lock hang (not necessarily an info-loop, >e=2Eg=2E a nasty regexp explosion) by leaning on `C-g` (the actual behavi= or >sucks, because the quit is caught by the redisplay which then jumps >right back into the same jit-lock code, toh apparently there's a bit of >progress made along the way, hence the need to lean on `C-g` for a while)= =2E Agreed=2E See my spec on the other thread=2E In terms of that post, we'd b= reak out of redisplay when #quits >=3D M: this condition means we'd ignore = the inhibit-quit when deciding whether to Fsignal in response to a quit=2E = It's also worth putting an explicit maybe_quit at the end of redisplay_inte= rnal if we don't have one already=2E >Maybe `kill -USR2` would work better?=20 Thanks for reminding me to mention SIGUSR2=2E We'll treat it like #quits >= =3D M=2E > Still, while I agree that we >should generally inhibit quits during redisplay, inhibiting all quits is >a problem, so I often wish we had two notions of quits: the "normal >quit" and the "emergency quit", where the emergency quit puts more >emphasis on making sure we stop what we're doing than on preserving >a "clean" state (e=2Eg=2E I don't mind some redisplay glitches after an >emergency quit from jit-lock)=2E We'd still want to stay away from core >dumps, of course That's what I'm proposing=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Pip Cet , Lynn Winebarger , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982555623533 (code B ref 78737); Fri, 13 Jun 2025 14:40:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:39:16 +0000 Received: from localhost ([127.0.0.1]:47425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5Yp-00067U-Ip for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:39:15 -0400 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:44225) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQ5Yn-00067G-89 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:39:13 -0400 Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4530921461aso19577965e9.0 for <78737@debbugs.gnu.org>; Fri, 13 Jun 2025 07:39:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749825547; x=1750430347; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ld/IiRdzNgJCouV14SCHdvgmPURfx1CaadXicGGAAcM=; b=B1mvA6EAEws98kn2E35vO19s8dcmiVCO1MHWiGYJnll7hvux4Ze1JwU1UHMooxWNmP Fbp2YHNiHo24GDMj+imoxeGbq1s3aRqHBgZ7QvJgf19eYYo56t/GFt8nTztNBUBqrab8 paIf2eCIffjmVrc1PpKhWYV67mcmZIUuQLhQmp7EFQMKfMzrmCIQskYXQCskdg8dmqCN xm88PV7mxLCmuW+oXlmUSGwQUia7ib/Q4rf+vbbPvpaXNHlfE0Xp/0iZpxpOi/Gc3Q+P rC6a+lfF7Ra1cD4Pi+8Vu7fbODmyup8VQ+lSszuE9Sg5qS9aJZrcllzv6ZAeF1x0nZv9 M7Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749825547; x=1750430347; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ld/IiRdzNgJCouV14SCHdvgmPURfx1CaadXicGGAAcM=; b=Zf2EpPETtugSePZiFxjNyXz6f5zJG7/AZY6JYxTmg3NGXjUKulNgUs8eG4QPE6LTaO Mf5AxPBE/j4qeigTn1YGgNFtdSlMZFkfc0caRJ7h5SanC+e152mA/+gTagF4D9aWS23B YVXgjBh+30VENVAoNizWen3JzmP63JaL5kPmICY8tjzpxqzr6ygXYkwzZ1Tc7dS/3apM wa6mMHrznM6RDEv8rPiRetR4u2r27Uz14VaTzpglVhr4lH/lFCwU6IK34CCW6WD1h8Sq tzeUqn4J14CxauZqmZaezV9Jn3L8UaX8Zszre0SXDpPm9ejKQg2PgVcUIdM+gm9yKkhZ OaNw== X-Forwarded-Encrypted: i=1; AJvYcCVNfEULGYPL/tOZcX5kDmq/ifqPOsSf1aP0StubmF8f3AE74O0gv4n8rryG7GRlBeWnXdA5TA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwZPkjrbjHi1tQ+2feefFHkn8hNHf6OCEF0xJrBMc0kp3b19KWt mPRHMKmDmu5ZL74K9q1zeU+PJT2GCgZbK3k8ZkchYITYWTpZrPLo+q9J X-Gm-Gg: ASbGncuM4hcOVd5w8srCCMP2ANwqD9/rq0UOuJpSFLH9HCAFHXcbhZEtw4ZtrmQ9zzX DStUPOKG4xOSMoPlPYE/2sOHCyVoe7weryLmnmbKFZdIb2pWy2SPuHiX8GC+ufrUnINi8OdwM7D bkFKrxu1VQ08GfpVYAcYpqip2MO0MSyO7ptUdrs4dGjxYLonKoPhrf/PitpiEDRg5YnPFiOIIsY 7dr+aT/izrmghVjBOr3n8EjM4vR6dqeSTXyOk718coVbnkElhBiIkT+eHOKlwAsT26ZACCw0Kaa atlKng5+ScMufXQ+8YOHU1TvWkRdWNKAXp6usA0GrsKYOEeizjkUHr6VY8w7RLMd6nBHiJ69uj5 tnP3c6Cqo9ak+YdV1SlOCXIxhwDCrHmrYVkam58qXC4A1MmNSbpvR75KIe9eVyVW+c1VsPJc= X-Google-Smtp-Source: AGHT+IHyLNmrJEt948Yh243aZyQnI6oRR0BLaqE/KtgH+E3NGpHLMpPM46oLMuFUoUc1T069XrD6Wg== X-Received: by 2002:a05:600c:190f:b0:43c:fe90:1282 with SMTP id 5b1f17b1804b1-45334a6d16emr30308415e9.7.1749825546577; Fri, 13 Jun 2025 07:39:06 -0700 (PDT) Received: from pro2 (p200300e0b704ee00104b88b47a1a54cc.dip0.t-ipconnect.de. [2003:e0:b704:ee00:104b:88b4:7a1a:54cc]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4532e14f283sm54471525e9.27.2025.06.13.07.39.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Jun 2025 07:39:06 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: <24B8C58B-D7CE-4596-A685-867B49EE4343@dancol.org> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> <24B8C58B-D7CE-4596-A685-867B49EE4343@dancol.org> Date: Fri, 13 Jun 2025 16:39:05 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) Daniel Colascione writes: > On June 13, 2025 7:01:01 AM PDT, "Gerd M=C3=B6llmann" wrote: >>Daniel Colascione writes: >> >>> We already have something like that. :-) read-event already runs the >>> events it reads through special-event-map, right? >> >>Entirely unrelated, I just came across this because I searched for >>read-event. Let me just mention that read-event does not respect >>input-decode-map. This is a problem on ttys, see bug#75886. > > > Seems at least a little related, doesn't it? It's another example of a > real world problem caused by inconsistent input reading strategy, > isn't it? True :-). And C-g in this case is an escape sequence, and so on. My old friend keyboard.c :-(. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982601825449 (code B ref 78737); Fri, 13 Jun 2025 14:47:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:46:58 +0000 Received: from localhost ([127.0.0.1]:47498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5gI-0006cP-3D for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:46:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41174) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ5g9-0006br-4G for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:46:50 -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 1uQ5g3-0006jU-HT; Fri, 13 Jun 2025 10:46:43 -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=UXxcew0LGCFIfZTZafJKEXQSgPVd0KxMmDpOTH2xdD0=; b=JSpWIL67zyKr 071tfunAAivd3IWLyRqHrkHgvDC+HaMVOgsNjgmgKJHVnytG/+Ql8KhberyAhRqE/2gzToosILGBL sLetSh2U9OJyj05E5gtuzDBxkYMyKhqbLHCmOwSGO8TYhYz26PJN9mp6lO+q0O2cMYZeRfgboXaos +z/zvZhwh1VtirWijNhuXtjXD364nfGiR1j3lKiTNPJpT9MSJ9nvPLpxGcAj0M9csOZ4KxahL6EGm cidjqbOfbIWn2nSjQ+ekbTWiD3MPOoj3DBcEG69r5QWSY4ZG1WeWunOAktAzuoek3zO6x7Kt5BW/4 910jvPe6h5/xK8HtPbrllw==; Date: Fri, 13 Jun 2025 17:46:41 +0300 Message-Id: <86cyb7em26.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8A57564E-70F3-49F6-8D77-1C947087DF8C@dancol.org> (message from Daniel Colascione on Fri, 13 Jun 2025 04:49:21 -0700) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86tt4kdw7r.fsf@gnu.org> <86ecvneuut.fsf@gnu.org> <8A57564E-70F3-49F6-8D77-1C947087DF8C@dancol.org> X-Spam-Score: -2.3 (--) 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: Fri, 13 Jun 2025 04:49:21 -0700 > From: Daniel Colascione > CC: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > > > > On June 13, 2025 4:36:42 AM PDT, Eli Zaretskii wrote: > >> From: Daniel Colascione > >> Cc: Pip Cet , monnier@iro.umontreal.ca, > >> 78737@debbugs.gnu.org > >> Date: Fri, 13 Jun 2025 00:53:38 -0700 > >> > >> > If you are talking about a GUI session, then IME the 'emergency exit" > >> > procedure isn't reliably working in that case, and I'm not sure the > >> > implementation intends to support that. I always knew that it's only > >> > reliably working on TTY frames. > >> > > >> > Or are you talking about the effect of the changes on the branch? > >> > >> FWIW, the purpose of my N-times-in-T-milliseconds-within-one-command > >> formulation of emergency exit is to get the mechanism working reliably > >> in all cases. > >> > >> I can definitely type 4-5 C-gs in a GUI Emacs (well, NS, but I recall > >> PGTK being similar?) and not have Emacs quit. If I mash C-g, it > >> sometimes does, and sometimes doesn't. > >> > >> Right now, the logic is this: > >> > >> { > >> /* Request quit when it's safe. */ > >> int count = NILP (Vquit_flag) ? 1 : force_quit_count + 1; > >> force_quit_count = count; > >> if (count == 3) > >> Vinhibit_quit = Qnil; > >> Vquit_flag = Qt; > >> } > >> > >> IOW, the first quit after clearing Vquit_flag resets the count to one. > >> Maybe that's why it isn't working reliably right now. If we reformulate > >> this mechanism not in terms of count == 3 (which is fiddly for all sorts > >> of reasons, since Vquit_flag can get reset) but in terms of the UX > >> directly --- N recent quits in T time in a single command --- we make > >> the whole thing more reliable. > >> > >> If you set T=infinity and N=3, you get the current force quit UX (modulo > >> my upgrade-before-disabling-inhibit-quit thing), just more reliably, and > >> you can break out of arbitrary Lisp code. > > > >I suggest to leave the emergency exit feature alone for now, and focus > >on the interruptibility of Lisp programs. > > That *is* the interruptabiltity of Lisp programs.l No, not in my book. A Lisp program should be interruptible without killing the Emacs session. "Emergency exit", OTOH, kills the Emacs session. So we should discuss these two features separately. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982616425831 (code B ref 78737); Fri, 13 Jun 2025 14:50:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:49:24 +0000 Received: from localhost ([127.0.0.1]:47522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5id-0006iZ-Tt for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:49:24 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:55258) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ5ib-0006iP-QS for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:49: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=jYGhUoiIxWinZkRsne7/ei62299CDXT4b3TPfY/T4zc=; b=TtIL2zeXK06kgTpmfkmOT56oBR r7fhMFkGTOv1tNXoda3mhXErneQBvde5OHnwdI/7GKdH9Ey2aujE3fGDg5vsmg579nOGxMXm+F6Xv uPc5n4mNpdS6osJ/iM2mprYVpWicSBD1rJ5hdjfx4wCjqW3doqriaw3+LiWpRcvEQV+uiv28CIRXk hjDuwdm2UQZI3EgTZJEVntUWSjrw/BPDJ6/6zHflNi+L/ufFdIV/1lrzYKPxgDdbj7r1506nHDRST OAxrjN5cLTu44l6nkqr70axkCu4+zedz/fTDzgXzwshQehHPN/slMxpxgrZcjlCNvBlIoOjinY8GQ NVxM31DQ==; Received: from [164.86.9.12] (port=32296 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 1uQ5h7-00Btqf-2o; Fri, 13 Jun 2025 10:47:50 -0400 Date: Fri, 13 Jun 2025 07:48:54 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <86cyb7em26.fsf@gnu.org> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86tt4kdw7r.fsf@gnu.org> <86ecvneuut.fsf@gnu.org> <8A57564E-70F3-49F6-8D77-1C947087DF8C@dancol.org> <86cyb7em26.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-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 June 13, 2025 7:46:41 AM PDT, Eli Zaretskii wrote: >> Date: Fri, 13 Jun 2025 04:49:21 -0700 >> From: Daniel Colascione >> CC: pipcet@protonmail=2Ecom, monnier@iro=2Eumontreal=2Eca, 78737@debbug= s=2Egnu=2Eorg >>=20 >>=20 >>=20 >> On June 13, 2025 4:36:42 AM PDT, Eli Zaretskii wrote: >> >> From: Daniel Colascione >> >> Cc: Pip Cet , monnier@iro=2Eumontreal=2Eca= , >> >> 78737@debbugs=2Egnu=2Eorg >> >> Date: Fri, 13 Jun 2025 00:53:38 -0700 >> >>=20 >> >> > If you are talking about a GUI session, then IME the 'emergency ex= it" >> >> > procedure isn't reliably working in that case, and I'm not sure th= e >> >> > implementation intends to support that=2E I always knew that it's= only >> >> > reliably working on TTY frames=2E >> >> > >> >> > Or are you talking about the effect of the changes on the branch? >> >>=20 >> >> FWIW, the purpose of my N-times-in-T-milliseconds-within-one-command >> >> formulation of emergency exit is to get the mechanism working reliab= ly >> >> in all cases=2E >> >>=20 >> >> I can definitely type 4-5 C-gs in a GUI Emacs (well, NS, but I recal= l >> >> PGTK being similar?) and not have Emacs quit=2E If I mash C-g, it >> >> sometimes does, and sometimes doesn't=2E >> >>=20 >> >> Right now, the logic is this: >> >>=20 >> >> { >> >> /* Request quit when it's safe=2E */ >> >> int count =3D NILP (Vquit_flag) ? 1 : force_quit_count + 1; >> >> force_quit_count =3D count; >> >> if (count =3D=3D 3) >> >> Vinhibit_quit =3D Qnil; >> >> Vquit_flag =3D Qt; >> >> } >> >>=20 >> >> IOW, the first quit after clearing Vquit_flag resets the count to on= e=2E >> >> Maybe that's why it isn't working reliably right now=2E If we refor= mulate >> >> this mechanism not in terms of count =3D=3D 3 (which is fiddly for a= ll sorts >> >> of reasons, since Vquit_flag can get reset) but in terms of the UX >> >> directly --- N recent quits in T time in a single command --- we mak= e >> >> the whole thing more reliable=2E >> >>=20 >> >> If you set T=3Dinfinity and N=3D3, you get the current force quit UX= (modulo >> >> my upgrade-before-disabling-inhibit-quit thing), just more reliably,= and >> >> you can break out of arbitrary Lisp code=2E >> > >> >I suggest to leave the emergency exit feature alone for now, and focus >> >on the interruptibility of Lisp programs=2E >>=20 >> That *is* the interruptabiltity of Lisp programs=2El > >No, not in my book=2E A Lisp program should be interruptible without >killing the Emacs session=2E "Emergency exit", OTOH, kills the Emacs >session=2E Maybe we're talking past each other? I'm not proposing anything that autom= atically kills Emacs=2E I'm not sure what would have given you the impressi= on we were talking about killing Emacs=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982631626691 (code B ref 78737); Fri, 13 Jun 2025 14:52:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:51:56 +0000 Received: from localhost ([127.0.0.1]:47560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5l5-0006wP-Mb for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:51:56 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37314) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ5l2-0006up-Bv for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:51:53 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 677C6441289; Fri, 13 Jun 2025 10:51:46 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749826301; bh=bEsRkNxhXzwlGqxw1p2zj5OlIbtF49v3xllcBlTBPkk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=X4P83OhhW54a0OPZLeMsoLJKM87Nz8gRaQpFgksSSOX7Zl1YueYgvl7wrjMD1IA1k aMakilWD9nRypClYsHg3jscJi4xd4aQB2ulF+Ol9l+oAlgg4fq61/In0lCqnxlQaFt vVCLSurjxFC4DYGt3daPF4K/KrhnusQ5NmThplVubi2BNUS8zwOCZskwJ9y48vr3pc 64Hhy4GOb163ex6Pv/KMYQDAscoFExJ0MS5SYDKOB2FMkGXML/KjFHZTtyDQtQFzu7 iaVgKYEsTxHf22gxtDs4hy1kaHXw5qF8bT1NweEslYFuvv7nXMYqlrgnl+px7yI39y 34yzSHJ4KiegQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 45CD24408F5; Fri, 13 Jun 2025 10:51:41 -0400 (EDT) Received: from asado (unknown [130.159.220.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id F02A01204E2; Fri, 13 Jun 2025 10:51:39 -0400 (EDT) From: Stefan Monnier In-Reply-To: <87bjqu1ho9.fsf@protonmail.com> Message-ID: References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> Date: Fri, 13 Jun 2025 10:51:37 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.000 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > Making > > (while t (read-event)) > > infloop without being able to quit is a bad idea. We shouldn't do it. I don't find this terribly problematic, If you think of what that loop means it *is* a "please shoot me in the foot" kind of thing. I agree that not being able to escape is a problem, but it's not the only way to get into such trouble. IOW I think it just gets us back to the fact that we need an "emergency quit" for bugs (which `kill -USR2` can sometimes provide, tho it's not a quit per-se). Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982643627125 (code B ref 78737); Fri, 13 Jun 2025 14:54:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:53:56 +0000 Received: from localhost ([127.0.0.1]:47626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5n1-00073R-NO for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:53:56 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64367) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ5mz-00073E-DE for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:53:53 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id F35CC1002F0; Fri, 13 Jun 2025 10:53:47 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749826427; bh=0mUgn8zqXHp60YNVcVbbBSceizsnT4++lo8aoOrGRmQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=AsUnwITGXNi/cLQadAm3tZMLhArSHUq1GD1Q+GPf1rUVB8Kv7hcveQKyOSemyjGbq nyYgoN45RuICl29juchEY5InQk9dFy0reSR5Hg9r6rM8x4Z68ohwan/YAR+Kr0xBwK BypgDzA5Suxu4Nc+j4uuaYMUEf7+zC04yTjIfXuO9Ub+0f79q25pkLHWaWh5kW0nHP AIBaYBSA7qHwW5EzDkLFPPW3Ik+76UmMRKDnhZYqt3aY+V8vS7PhY9+Rx60yzRj84S qYBgBMBCqyLfp5yq9RuKwlucZGvSwk2VoA+b3VFaI1poCwU+FlLeDa6iGQZtKbNOoP mE+Indmpr2Q6A== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 05922100034; Fri, 13 Jun 2025 10:53:47 -0400 (EDT) Received: from asado (unknown [130.159.220.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CBA65120444; Fri, 13 Jun 2025 10:53:45 -0400 (EDT) From: Stefan Monnier In-Reply-To: <875xh21f2w.fsf@protonmail.com> Message-ID: References: <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <875xh21f2w.fsf@protonmail.com> Date: Fri, 13 Jun 2025 10:53:43 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > - ;; FIXME: we should not read-event here at all, because it's much too > - ;; difficult to reliably "undo" a read-event by pushing it onto > - ;; unread-command-events. > - ;; For bug#14782, we need read-event to do the keyboard-coding-system > - ;; decoding (hence non-nil as second arg under POSIX ttys). > - ;; For bug#15614, we need read-event not to inherit-input-method. > - ;; So we temporarily suspend input-method-function. > - (let ((read (let ((input-method-function nil)) > - (read-event nil t seconds)))) > - (or (null read) > - (progn > - ;; https://lists.gnu.org/r/emacs-devel/2006-10/msg00394.html > - ;; We want `read' appear in the next command's this-command-event > - ;; but not in the current one. > - ;; By pushing (cons t read), we indicate that `read' has not > - ;; yet been recorded in this-command-keys, so it will be recorded > - ;; next time it's read. > - ;; And indeed the `seconds' argument to read-event correctly > - ;; prevented recording this event in the current command's > - ;; this-command-keys. > - (push (cons t read) unread-command-events) > - nil)))))) > + (not (if throw-on-input > + (sleep-for seconds) > + (while-no-input (sleep-for seconds))))))) I'm not sure this will wake up on the same events (i.e. whether its notion of what is "not a real input event" is the same). `sit-for` has seen several iterations because of "corner cases", so I wouldn't be surprised to bump into regressions, but I agree that it would be nice to "align" the notion of "relevant" events used by `sit-for` with that used by `while-no-input`. [ IIRC part of the differences are the events handled by `special-event-map`. ] Note also that I'm not sure `sleep-for` will actually do what we want here (does it run process filters and timers? And update the display accordingly?). Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 14:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982649627403 (code B ref 78737); Fri, 13 Jun 2025 14:55:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:54:56 +0000 Received: from localhost ([127.0.0.1]:47649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5nx-00077t-AB for submit@debbugs.gnu.org; Fri, 13 Jun 2025 10:54:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47728) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ5ns-00076I-20 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 10:54:51 -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 1uQ5nm-0007su-2v; Fri, 13 Jun 2025 10:54:42 -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=H3f/IQ0fIqzIKX/Vh6kK2KNwgKx+0TzIS1bt1tMCkb0=; b=G58JQ7i88urj cKCqmZNdwpg4EhPOu17F+YqwPhJjWgJylO2w7muBDT378hpbRjRbiEcKXB1+VT4JlIxASclDUoKco Z3BMwDUYmJH03HjkPpLLGQ4j67zJitovX/x8LGzo4EalJhxs4XlY+Y0/VR0zBbCiVFVl9OE9FyLGn /WXF+RZMZKkReP9SOoGKF6m+ztDl8YehdiYT8YdmWWAssT6dAeyj2mZGK7/Ms4iDB0owCHPqhFlLm /iULgJ0S04n+9ry/rhKj+52QOxvtcRKwdQczYBnyPCHeDktgOoasOjkEGMOUn9+zKip/Lg26Cbimu wu58GxJncoXk3/KgsWqBbA==; Date: Fri, 13 Jun 2025 17:54:40 +0300 Message-Id: <86a56belov.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87v7ozygih.fsf@protonmail.com> (message from Pip Cet on Fri, 13 Jun 2025 12:26:19 +0000) References: <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86tt4kdw7r.fsf@gnu.org> <87v7ozygih.fsf@protonmail.com> X-Spam-Score: -2.3 (--) 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: Fri, 13 Jun 2025 12:26:19 +0000 > From: Pip Cet > Cc: dancol@dancol.org, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > > "Eli Zaretskii" writes: > > >> (while t > >> (let ((inhibit-quit t)) > >> (read-event))) > >> > >> quittable, as I naively expected it to be. The old behavior would > >> remain available, but require an extra let binding. > > > > But isn't it confusing that to have something quittable one needs to > > bind inhibit-quit non-nil? > > I'm confused: the code above should be quittable whether or not the > "let" line is present, as long as the "let" line comes after the "while" > line: we unbind inhibit-quit after each iteration, and I'm expecting > Emacs to take this opportunity to quit. You are looking at this from the implementation POV, while I look at this from the user POV. Telling users to bind inhibit-quit non-nil to make a program quittable will make very little sense to users. > >> Note that this isn't > >> > >> (let ((inhibit-quit t)) > >> (while t > >> (read-event))) > > > > Which is also confusing by its inconsistency. In general, the order > > of let-bindings doesn't matter. > > I don't see how it's inconsistent, sorry. If I bind inhibit-quit and > keep it bound while clearing quit-flag, I get an unquittable loop. If I > repeatedly bind and unbind inhibit-quit so it becomes nil once per > iteration, I should get a quit when it does become nil, after the > binding has been unwound but before the next iteration's binding goes > into effect. You are again looking at the implementation aspects. > >> Situation 3: > >> > >> Several force-quits in the same session. Reset force_quit_count to 0 > >> once it reaches 3. I've seen force_quit_count reach higher values than > >> 3 (there was no regular quit in between force quit attempts). > > > > If you are talking about a GUI session, then IME the 'emergency exit" > > procedure isn't reliably working in that case, and I'm not sure the > > implementation intends to support that. I always knew that it's only > > reliably working on TTY frames. > > I'm talking about the GUI case, yes. > > It seems like an oversight to me. Two successive emergency quits don't > work if both of these conditions hold: > > 1. there's no intervening regular C-g > 2. quit-flag is non-nil > > So a recipe would be: > > (let ((inhibit-quit t)) > (setq quit-flag t) > (while t)) > > C-x C-e > C-g C-g C-g > C-x C-e > C-g C-g C-g > > Expected outcome: two emergency quits > Actual outcome: one emergency quit, no further emergency quits possible. I suggest to leave the emergency exit feature alone for now, and focus on the interruptibility of Lisp programs first. We have enough issues to agree on and fix there. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 15:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Pip Cet Cc: 78737@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982704230254 (code B ref 78737); Fri, 13 Jun 2025 15:05:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:04:02 +0000 Received: from localhost ([127.0.0.1]:47888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5wo-0007ru-2y for submit@debbugs.gnu.org; Fri, 13 Jun 2025 11:04:02 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:33880) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ5wk-0007rR-Jq for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 11:03:59 -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=bGC6dqNrsAzO+APRnPiyswyyhoKp9dWZ/6gOeCOwmGA=; b=Kk0y1s2eNc21qjNRqUpPwn+6I3 OSMyjYgw+WC0ITa2hSzyFq2Uw7/zURkLqZNCD/ZZaJ/knsIitHsnyLNW1Qot5/v9PJlRT7MQ9X3YF 14vt0iqsOCeqZiVcb7okAe713dSFBVCizMbZ/xbYynMiuAky9myKyORmSahXLQDPwMKjEGnq2IPh/ GP5MwwWnHQAFOa8PL0yeekZiD81qnGPzJOSjCuVN5V00bZtAYr9hxBN2KGCc3vI2+xJuINsqKE5ta SWK1mKkdH0tLwuX881Uu3DphPMiqoStZytLn0yKM6qJ2CM/OMgR2OW/ZvKWtynYSEekqfQgTscL9+ NmPywCpQ==; Received: from [164.86.9.12] (port=39314 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 1uQ5vG-00BttG-0I; Fri, 13 Jun 2025 11:02:27 -0400 Date: Fri, 13 Jun 2025 08:00:04 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <86a56belov.fsf@gnu.org> References: <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86tt4kdw7r.fsf@gnu.org> <87v7ozygih.fsf@protonmail.com> <86a56belov.fsf@gnu.org> Message-ID: <7C75C53D-FB46-42D2-BECC-BB1F5BBCABF1@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 13, 2025 7:54:40 AM PDT, Eli Zaretskii wrote: >> Date: Fri, 13 Jun 2025 12:26:19 +0000 >> From: Pip Cet >> Cc: dancol@dancol=2Eorg, monnier@iro=2Eumontreal=2Eca, 78737@debbugs=2E= gnu=2Eorg >>=20 >> "Eli Zaretskii" writes: >>=20 >> >> (while t >> >> (let ((inhibit-quit t)) >> >> (read-event))) >> >> >> >> quittable, as I naively expected it to be=2E The old behavior would >> >> remain available, but require an extra let binding=2E >> > >> > But isn't it confusing that to have something quittable one needs to >> > bind inhibit-quit non-nil? >>=20 >> I'm confused: the code above should be quittable whether or not the >> "let" line is present, as long as the "let" line comes after the "while= " >> line: we unbind inhibit-quit after each iteration, and I'm expecting >> Emacs to take this opportunity to quit=2E > >You are looking at this from the implementation POV, while I look at >this from the user POV=2E Telling users to bind inhibit-quit non-nil to >make a program quittable will make very little sense to users=2E I *am* talking about this from the UX POV, and nobody AFAICT is proposing = a mechanism that involves a program becoming quittable when adding a t bind= ing to inhibit-quit=2E I agree that's a bad idea=2E That's why nobody is su= ggesting it=2E >> >> Note that this isn't >> >> >> >> (let ((inhibit-quit t)) >> >> (while t >> >> (read-event))) >> > >> > Which is also confusing by its inconsistency=2E In general, the orde= r >> > of let-bindings doesn't matter=2E >>=20 >> I don't see how it's inconsistent, sorry=2E If I bind inhibit-quit and >> keep it bound while clearing quit-flag, I get an unquittable loop=2E I= f I >> repeatedly bind and unbind inhibit-quit so it becomes nil once per >> iteration, I should get a quit when it does become nil, after the >> binding has been unwound but before the next iteration's binding goes >> into effect=2E > >You are again looking at the implementation aspects=2E How many times do I have to put the situation in terms of UX? I mention us= er experience over and over, yet I see you insist I'm not considering UX=2E= What specific aspect am I not considering? > >> >> Situation 3: >> >> >> >> Several force-quits in the same session=2E Reset force_quit_count t= o 0 >> >> once it reaches 3=2E I've seen force_quit_count reach higher values= than >> >> 3 (there was no regular quit in between force quit attempts)=2E >> > >> > If you are talking about a GUI session, then IME the 'emergency exit" >> > procedure isn't reliably working in that case, and I'm not sure the >> > implementation intends to support that=2E I always knew that it's on= ly >> > reliably working on TTY frames=2E >>=20 >> I'm talking about the GUI case, yes=2E >>=20 >> It seems like an oversight to me=2E Two successive emergency quits don= 't >> work if both of these conditions hold: >>=20 >> 1=2E there's no intervening regular C-g >> 2=2E quit-flag is non-nil >>=20 >> So a recipe would be: >>=20 >> (let ((inhibit-quit t)) >> (setq quit-flag t) >> (while t)) >>=20 >> C-x C-e >> C-g C-g C-g >> C-x C-e >> C-g C-g C-g >>=20 >> Expected outcome: two emergency quits >> Actual outcome: one emergency quit, no further emergency quits possible= =2E > >I suggest to leave the emergency exit feature alone for now, and focus >on the interruptibility of Lisp programs first=2E We have enough issues >to agree on and fix there=2E The emergency exit aspect of the proposal is *how* we ensure that all Lisp= programs can be interrupted=2E I am not proposing that we make some Lisp = programs uninterruptible=2E I am not proposing some system for automaticall= y killing Emacs=2E I am proposing a more robust version of the mechanics we= already have=2E Normal users in ordinary use will not see a UX difference,= except on NS, where quits will start working reliably where they don't tod= ay=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 15:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982708030386 (code B ref 78737); Fri, 13 Jun 2025 15:05:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:04:40 +0000 Received: from localhost ([127.0.0.1]:47907 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ5xP-0007u2-Q0 for submit@debbugs.gnu.org; Fri, 13 Jun 2025 11:04:40 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34066) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ5xN-0007tp-Ol for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 11:04:38 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 128D71000BC; Fri, 13 Jun 2025 11:04:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749827071; bh=nM7GweKQghWdPEMG/sJB16LGpg1jFtcpCDyOuLKaC6o=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=fTLCo83QVF3VFkdlYAMA0uYdE3nUNyguTbiRWaWIY2LMjL+Wb8YIuBeOj/4TX4+Qw X55lzcIiQ3UXEgg2jx+Q2oGJcJojCL2Z/Eyf1A7i8ywh4+tHqt5n5O+QED54ZqlhpZ CqCyszOzia4gBiJnbPtGWOVyb6gHbv5D1+jiT77vu7DCS3N0ueorb3Lep8wO5ZS6xe XP7qFfQJW655EjAKQqvadN/8Zg+RS5NzDYu2TkcbcHsKInovpefVSVN+qKcbIUTy6P WTFQcGh2wCcMj7wW4GhcNHsRMVXMte4D/+6bKucW1BqNSw83Qi8eqRpkWsX7zYbIM2 l4yuStm5Mvijg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1A3A110002E; Fri, 13 Jun 2025 11:04:31 -0400 (EDT) Received: from asado (unknown [130.159.220.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AF835120604; Fri, 13 Jun 2025 11:04:29 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86jz5ie7j7.fsf@gnu.org> Message-ID: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <86jz5ie7j7.fsf@gnu.org> Date: Fri, 13 Jun 2025 11:04:27 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > This code is used everywhere, and we have no one on board who knows it > (and its many quirks and platform-dependent subtleties) well enough. > It isn't an accident that we prefer not to make changes in it: each > time we made even small changes in this code we ended up with > regressions. We don't have any decent test suite for the this part of > Emacs. We don't even have an exhaustive list of > features/commands/operations to test in order to make sure some change > doesn't break them. Notable corners that get frequently broken by > changes in this area: keyboard macros, Leim input methods, and > non-keyboard input events. Yes, that's what I see as the main benefit of Daniel's suggestion: it makes the behavior a bit simpler to describe (assuming there isn't some nasty implementation detail which leaves some corner case open), so it would help make that code a bit more manageable. Ideally it should come with some documented design rationale of how `inhibit-quit` is expected to be used and behave in general (i.e. in what kind of circumstances it should be bound and where/when it shouldn't, ...). I have no delusion that it can be done without introducing some regressions. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 15:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, Daniel Colascione Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982738632240 (code B ref 78737); Fri, 13 Jun 2025 15:10:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:09:46 +0000 Received: from localhost ([127.0.0.1]:48050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ62L-0008Nw-Vo for submit@debbugs.gnu.org; Fri, 13 Jun 2025 11:09:46 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:11512) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ62J-0008Nj-Uk for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 11:09:44 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7A42A80898; Fri, 13 Jun 2025 11:09:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749827377; bh=8UDq4L5yy1mEPL7xTIMLag0O92Cor67e9GDexqUENi4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ByakfHP8cFyVEKAUhL6oAtGw6blZLaywWQPE9gTg3uH0ev+mJTFFdQmtJHGSJD37C 98gX/m8GQu+yqtpRCcWfJzDTfQ39osSHenPmeTsLirqLoh0Kxg5O0TpmBFgGtPZ5tJ wavx/ORMpIgJFatj//3jNOtbExV6fyCpaPMWE0EUk3prLaOtogyYqVBXV8Q073qVoT G/Y7KTv5I3OKoQQvILWsQ9LXOD+MkccBa0WLMF5JXcB7q2vC8NPkqEDrTCDy28b5k0 4IvEjLaGQV3YokS4lz2SOp58KIeH81T6EQCu21UhUv11+YRrgzjetM0yrB2Q0wVgIy lyQcpxuqTMgPw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C13D780822; Fri, 13 Jun 2025 11:09:37 -0400 (EDT) Received: from asado (unknown [130.159.220.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4C79412023A; Fri, 13 Jun 2025 11:09:36 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86y0twerm0.fsf@gnu.org> Message-ID: References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> <86y0twerm0.fsf@gnu.org> Date: Fri, 13 Jun 2025 11:09:33 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.132 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > Specifically, what I'm interested in is how come > > (while t > (read-event)) > > cannot be interrupted by C-g, but you seem to be saying that > > (while t > (let (evt (read-event)) > (do-something-with evt))) > > _can_ be interrupted? Usually the `(do-something-with evt)` part will offer some way to end the loop. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 15:25:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, Daniel Colascione Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982828516824 (code B ref 78737); Fri, 13 Jun 2025 15:25:03 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:24:45 +0000 Received: from localhost ([127.0.0.1]:48402 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ6Gp-0004N4-Er for submit@debbugs.gnu.org; Fri, 13 Jun 2025 11:24:44 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13791) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ6Gm-0004LV-Sk for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 11:24:41 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id A8F1A44151D; Fri, 13 Jun 2025 11:24:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749828273; bh=pZUlbvX5HIOQwY2wliihwF1+Evjl3U0xuKuIJY+aKf0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=TJsE02FgDxDmdgr9ML5XcJMsVnv/nodi9Jv7FIlWdGxZWTAhnm3gMuZYgfm4Pwzl3 Q3ssOsidshxCo2lJRObF/xMixYIsIbd9zErE0rq4X0xSdbGl6A1r8c8XOx7TtLtKXJ om/JY4MOlvpbwyLMZrbxHb0pUqyVvyDo4HdNAJGvH82/ITPiVEeh/MK6Pv3Z5SgKO8 T155Bjyos2KvA4i9dfgKbUENzv0BJJ9WdOZd9Nx0r9prR4fbklErfMbcV1wDx9yFVY nf3kHA+a9OkZHbsZPhFpozvoG7QupQr/EXTBSt2n4Y7FB7s7BPblmzXW/hcJoQfnR3 u0odiY6RL4Smg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id ACA554414EE; Fri, 13 Jun 2025 11:24:33 -0400 (EDT) Received: from asado (unknown [130.159.220.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 35529120637; Fri, 13 Jun 2025 11:24:32 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86sek4duov.fsf@gnu.org> Message-ID: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> Date: Fri, 13 Jun 2025 11:24:29 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.000 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > We should start by agreeing that the capability of interrupting a > running Lisp program is a real need. Are we in agreement about that? > If not, let's first hear the arguments why not. It's a real need, but there's also a real need for some ELisp functions to catch normal quits. So we can't have "normal quits" as the universal answer to "interrupting a running Lisp program". What we have instead is that "normal quit" should work to interrupt any well-behaved ELisp programs, plus it should also work to interrupt most other ELisp programs (IOW it shouldn't be hard to write well-behaved ELisp code), but there has always been and will always be cases where we need an "emergency quit" to interrupt some ELisp programs (and that feature has been missing in GUI builds for a while). Stefan PS: BTW, since we're talking about uses of `inhibit-quit`, I just remembered that correctness reasons, `unbind_to` *should* run with `inhibit-quit` set. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 15:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione , Pip Cet , Lynn Winebarger Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982888524118 (code B ref 78737); Fri, 13 Jun 2025 15:35:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:34:45 +0000 Received: from localhost ([127.0.0.1]:48438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ6QW-0006Gl-3y for submit@debbugs.gnu.org; Fri, 13 Jun 2025 11:34:45 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18268) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ6QT-0006FV-UF for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 11:34:42 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 526B580898; Fri, 13 Jun 2025 11:34:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749828875; bh=JGzl/hCo1THsY4+NkGwm41F4AyVgjFBfqLxcZVFxFbM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=nAcyz7B3LXpOSp1sK8SQsUlWDkF7M4wB7GfOzKbI2r1O4A7N22LEL35vsiAPxwU+h pb+8wMgeU92HJh3uHE9hGB5F1dxz4k4Qk8pSZ1US5mht5aTR0oJnJpud93IFslHOsG sCFdpJwJr9ZzL4rmqq6+vasFZjS5kzORE6gMBHKSzp/mfHKEzr+LhUHq68nTGSTaUv kYnu1tFVaTw2V761lln+GL6S0uHR+7H5jKM9z3FjsmED7RqREWuT16Xaz4XMgyuEmb jtD+Q7MWbH1PR+MLOw6JCCjsrdzmkmZclS1iLeJNBrTyeGNMjMWXuaVYduSian082H X/31PMEopB7FA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 87EFB807A8; Fri, 13 Jun 2025 11:34:35 -0400 (EDT) Received: from asado (unknown [130.159.220.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D154F1200A3; Fri, 13 Jun 2025 11:34:33 -0400 (EDT) From: Stefan Monnier In-Reply-To: Message-ID: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> Date: Fri, 13 Jun 2025 11:34:31 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.125 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> We already have something like that. :-) read-event already runs the >> events it reads through special-event-map, right? > Entirely unrelated, I just came across this because I searched for > read-event. Let me just mention that read-event does not respect > input-decode-map. This is a problem on ttys, see bug#75886. Currently the only "decoding" we have to turn the TTY input bytes into events is limited to the keyboard-coding-system thingy. =F0=9F=99=81 Maybe I should have implemented `input-decode-map` directly inside `read-event`, but I think it goes contrary to the design. It's usually better to change the users to use a higher-level function instead, such as `read-key`. Admittedly, if you want to recognize a quit event encoded as an escape sequence, that's not going to help you because we need/want those events to be decoded at as-low a level as we can. =F0=9F=99=81 Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 15:39:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione , Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174982911526329 (code B ref 78737); Fri, 13 Jun 2025 15:39:04 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:38:35 +0000 Received: from localhost ([127.0.0.1]:48463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ6U4-0006pC-Jd for submit@debbugs.gnu.org; Fri, 13 Jun 2025 11:38:34 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:34999) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ6Tq-0006mO-SK for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 11:38:21 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DA1E744151D; Fri, 13 Jun 2025 11:38:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749829076; bh=CuPL6tT55RQ9948Lq3cMA9vh8KMB/39mr/+pL66TORU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NnlidCeslYPF1l4g5fZd4kRYVJ5irl7n96oJfZz3ta6d7yG9rcKThwf626NffdQsy 3SCHtQfW1af2fDOcBE/r8u2IzfAmBqXJbD+Ki0s5bxrSY5Rnen4xvUK9kiIqOzOTKL 5X4YNek7gvPzPkUBfu6IzmzXau2cgJv+mZV/KInVEtXykSKMTvQrPmJCq4/hnTN6Fm 0TiE+v1C2TvR1AZAkie1kDO2oLBMGMnLj9ngX+Ha/V0+OQQN6uCiJlymWaplVtNtFH y7ge+qdcUZ2KnaTdswEJErK9Phnf4iSiKdP1nSAfgiSQwy27AWpDP+UskbqowmAhxv jnz6PbTUSaqLg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EE9404414ED; Fri, 13 Jun 2025 11:37:55 -0400 (EDT) Received: from asado (unknown [130.159.220.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3E6F41204A7; Fri, 13 Jun 2025 11:37:54 -0400 (EDT) From: Stefan Monnier In-Reply-To: Message-ID: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86frg3euz5.fsf@gnu.org> Date: Fri, 13 Jun 2025 11:37:51 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.000 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) Ladies and gentlemen, please let's try and keep this civil. Let's remember that misunderstandings and implicit assumptions are part of human life. Stefan Daniel Colascione [2025-06-13 06:35:40] wrote: > On June 13, 2025 4:34:06 AM PDT, Eli Zaretskii wrote: >>> From: Daniel Colascione >>> Cc: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org >>> Date: Fri, 13 Jun 2025 00:28:45 -0700 >>> >>> Eli Zaretskii writes: >>> >>> >> From: Daniel Colascione >>> >> Cc: Eli Zaretskii , monnier@iro.umontreal.ca, >>> >> 78737@debbugs.gnu.org >>> >> Date: Thu, 12 Jun 2025 11:48:50 -0700 >>> >> >>> >> Pip Cet writes: >>> >> >>> >> > I'd like read-event, when called while inhibit-quit is t, to report >>> >> > quits by setting quit-flag in addition to returning quit_char: it'll >>> >> > simplify the C code, and it would make >>> >> > >>> >> > (while t >>> >> > (let ((inhibit-quit t)) >>> >> > (read-event))) >>> >> >>> >> I strongly disagree. read-event should read an event. >>> >> Setting quit-flag by side effect when it happens to read one key and not >>> >> others makes the interface less regular and understandable. >>> > >>> > We should start by agreeing that the capability of interrupting a >>> > running Lisp program is a real need. Are we in agreement about that? >>> > If not, let's first hear the arguments why not. >>> >>> Which Lisp programs? >> >>All of them. > > Do you want a mechanism that can interrupt all Lisp programs or not? I have such a mechanism. > >>> One that calls (while t (read-event))? One that >>> calls (let ((inhibit-quit t)) (while t (read-event))? How about one >>> that calls (while t (read-key-sequence ""))? How about one that calls >>> (let ((inhibit-quit t)) (while t (read-key-sequence ""))? If you adopt >>> the tenet that Lisp programs always be uninterruptible, _something_ has >>> to change from the present, because 3/4 of my examples above cannot >>> be quit. >> >>So because we currently cannot interrupt some programs we should give >>up the ability to interrupt all of them? > > My proposal allows us to interrupt all Lisp programs. I don't know how many > times I have to say this to get the point across. > >> Please be serious. > > Please engage with what I'm saying and at least try to say things that make internal sense. > >>Arguments like the above are a red herring, and don't help advancing >>this discussion towards some kind of agreement. > > You just said above that we should consider the interruptabiltity of all > Lisp programs. I cited examples of Lisp programs. That means these Lisp > programs are relevant to the conversation, as they, being Lisp programs, > belong to the category of all Lisp programs. > >>Do you want the branch merged at some point? > > Do you want bugs fixed and behaviors improved at some point? > >> Then please drop the >>attitude and start participating in the discussion seriously. You >>understand very well what I meant above, even though it is somewhat >>vague. > > Actually, I have no idea what you mean: you say things like you're not sure > whether we can distinguish two C-g presses from a double C-g press. There > are the same thing. It's like asking whether we can distinguish #00f from > #0000ff. > >> We all know what Emacs can and cannot do today, so I allow >>myself not to write too many well-known details. >> >>Let's consider the current capabilities of interrupting Lisp programs >>as base line, and try to maintain that base line, if not improve on >>it. Okay? > > I'm suggesting being able to interrupt all Lisp programs. Not all Lisp > programs can be interrupted today. I have explained in multiple places how > that is to be done. I am happy to explain further if you give me some > substantial technical questions about the mechanisms involved. > > When Lisp writes (while t (some-event-reading-function)), programmer intent > is not clear. It's not clear because C-g is overloaded and can be either an > event or a quit command. On the one hand, the Lisp is running Lisp and we > have a general contract that Lisp can be interrupted with C-g. On the other > hand, Lisp is asking to read an event, and C-g can be an event. We have to > resolve the ambiguity SOMEHOW. Right now, Emacs resolves the ambiguity in an > inconsistent and ad-hoc manner. If the some-event-reading-function above is > read-event, we resolve the ambiguity in favor of quitting. If instead > some-event-reading-function is read-key-sequence, we resolve the ambiguity > in favor of event reading. This inconsistency is real, confusing, and > illogical. In my proposal, we resolve the ambiguity in favor of event > reading and use multiple C-g presses to indicate user intent to quit instead > of provide input. I don't believe there's a practical, real world use case > in which a single C-g will be insufficient, but the ability to press C-g > multiple times will be there regardless. If you'd like to configure your > Emacs to resolve the ambiguity in favor of quitting, you can do that by > changing one variable. Either way, behavior will be consistent among all > Lisp functions that read events. > > Would you please engage substantively with the previous paragraph instead of > calling it a distraction and then raising points germane to exactly what the > previous paragraph covers? > > Again, nobody is talking about making users count C-g. Nobody is talking > about requiring multiple C-g presses in any real world case. The change I'm > talking about will make Emacs more consistent, and I've yet to see anything > in the real world it would break. > > My change also makes Emacs safer, because in my model, you *can* break out > of (while t (read-key-sequence)) and in master today you cannot. There will > be *one* uniform and consistent (and easy to understand) model for how we > address the *inherent* ambiguity about what control-g on a keyboard means. > > Or does it still not satisfy your intentionally-pedantic >>interpretation of what I write? > > I wouldn't have to be pedantic if you would be clear about what you want. > >>> > If we _are_ in agreement about that, should discuss how this should >>> > be possible if read-event (and perhaps others?) return C-g instead of >>> > raising quit-flag. The alternatives mentioned until now are: >>> > >>> > . restore the old behavior, whereby C-g interrupts read-event >>> >>> Does not satisfy the "lisp programs always be >>> interruptible" requirement. >>> >>> > . have a variable that, if set, will restore the old behavior in >>> >>> Same as above. >>> >>> > read-event and other affected primitives, to be interruptible by a >>> > single C-g >>> >>> Same as above. >> >>Please reconsider your responses with a more serious and cooperative >>attitude. > > Then make some sense. You talk about requirements. I explain how we meet > those requirements. That's pedantry? > >>> > . make two C-g presses "in quick succession" set quit-flag, IOW >>> > "C-g C-g" will have the same effect as C-g previously >>> >>> Only for read-event. >> >>Why "only"? >> >>Having the behavior vary depending on whether the program does or >>doesn't call read-event will bring inconsistency, something we want to >>avoid (and which I think you argued against). > > It is logically impossible to combine two things: > > 1) all Lisp programs can be interrupted with a single C-g > > 2) a Lisp program can read a C-g as an event. > > This isn't pedantry. It's foundational logic. Demanding a solution that > satisfies both constraints is impossible. It would require reading the > user's mind. > >>> If you want to adopt a principled stance that every Lisp program be >>> interruptible, you necessarily, as a matter of logic, regard multiple >>> behaviors of current Emacs to be bugs worth fixing. >> >>Not useful. I didn't mean that, and you know it. > > You just said at the start of this email that you're considering the > interruptabiltity of all Lisp programs. I have a scheme to make all of them > interruptible. Nobody else has proposed one. > >>> > Are there other alternatives? >>> >>> Get in a time machine, go back 40 years and stop overloading C-g? >> >>Even less useful. Again, do you want this branch to be merged any >>time soon? Because I'm this close to losing my patience. Life's too >>short to waste it on "arguments" such as this one. >> > > And I'm losing patience with objections that contradict themselves and fail to address my points. > >>> > I don't think there's disagreement on that level. So let's drop this >>> > kind of arguments, because they are not useful for this discussion. >>> > The problem we face is how to allow Lisp code to be quittable. A Lisp >>> > program that calls read-event is not different from a Lisp program >>> > calling any other function, so we still need such programs to be >>> > quittable somehow. Let's discuss how best to do it, okay? >>> >>> Yes or no: should (while t (read-key-sequence)) be quittable? >> >>Why is that relevant? > > If you'd like to cooperate seriously, I'm happy to do so provided you do so > as well, and part serious cooperation is answering clarifying technical > questions instead of questioning their relevance. > > So, yes or no? > >> I asked about read-event, not >>read-key-sequence. Can we first discuss the read-event case? Once we >>are done with that, we can move to other cases. > > You just said above you want to consider the interruptabiltity of all Lisp > programs. Now you're calling the interruptabiltity of some Lisp programs > irrelevant. Which is it? > > It's important to consider the input model as a whole. I don't think we can > get to a good place by focusing on one function at a time and be wilfully > oblivious about whether different functions together form a coherent whole. > >>> If yes, maintaining today's behavior isn't an option. There are plenty >>> of other Lisp programs that cannot be quit --- even (let ((inhibit-quit >>> t)) (while t)) cannot be quit! >> >>If inhibit-quit is bound to a non-nil value, the program cannot be >>quit, and that's a feature. > > This seems like both a contradiction and poor UX: you want some Lisp > programs to be interruptible and others not. Why is it a feature that some > Lisp programs cannot be quit? I thought you wanted to talk about all Lisp > programs being quittable. Why is it desirable that Emacs be left in an > unrecoverable state? > > In my proposal, users will be able to interrupt *any* program of the form > (let ((inhibit-quit t)) (while t (anything))) by pressing C-g enough times > to override the inhibit-quit. Emacs already provides this feature, but only > (AFAICT) on primary TTYs. > > If this ability to break out of a loop wrapped in inhibit-quit is bad, > should we remove the existing force-quit feature? Yes or no, please. > > My proposal is a generalization of a feature we've had for decades. It is not a brand new concept. > > Is it a bug to allow these programs to be interrupted? Yes or no. If yes, > why isn't the existing force quit feature being removed? If not, why is > being unable to quit some Lisp programs a "feature"? > > You say I know what you mean. I'm really not sure I do, because from where > I'm sitting, you're not answering questions that would resolve the > contradictions in what you're saying. > >> Why are we discussing this? > > > Because we're talking about interrupting Lisp programs. That's the subject > of the whole conversation. > >> >>> If no, what is the problem with cleaning up Emacs by regularizing how we >>> treat C-g as an event versus some kind of longjmp? >> >>Again, let's discuss the read-key-sequence case after we are done with >>the read-event case. > > How can we consider what to do with read-event without thinking about how it > fits into the broader picture? > >>> >> > Several force-quits in the same session. Reset force_quit_count to 0 >>> >> > once it reaches 3. I've seen force_quit_count reach higher values than >>> >> > 3 (there was no regular quit in between force quit attempts). >>> >> >>> >> Get rid of force_quit_count entirely and just detect (by writing into a >>> >> ring buffer) whether we've received N quits in the last T milliseconds. >>> >> That'll work the same way regardless of how quits gets detected. We can >>> >> change N and T freely. >>> > >>> > This is the last alternative I described above. It is IMO less >>> > desirable, because it is not always easy to press C-g twice quickly, >>> > for whatever reasons. It is even less desirable to define "quick >>> > succession" in terms of time, because timings can differ a lot >>> > depending on the free computing resources and the CPU power in >>> > general, so determining the best default values will be very >>> > challenging, to say the least. >>> >>> I don't see the ambiguity being a realistic problem. How often do you >>> press C-g three times while a single command is running? >> >>I usually expect a single C-g to quit. If it doesn't help, I can >>press C-g several times, I'm not sure I count them. > > In my proposal, on every real world case, C-g returns you to the command > loop when you want to go there and lets Lisp read C-g as an event when you > want to do that. You can construct buggy or pathologically written programs > that you can't exit with a single C-g because the meaning of that keystroke > is overloaded. You can still get back to the main loop in these rare cases > by pressing C-g repeatedly. You don't have to count them. You just keep > pressing C-g until you are back in the command loop, just like today's force > quit feature. > >>> We're not talking about, say, six times in multiple rounds of M-x this, >>> select that, deactivate mark over here. Those are multiple commands. >>> In between multiple commands, a C-g will cause a keyboard-quit and >>> you'll regain control over Emacs. I'm asking, during _one_ command, how >>> many times you typically press C-g and _don't_ mean it as a quit. >> >>See above. >> >>> We already have a force quit mechanism that kicks in at N=3. How often >>> do you activate it? >> >>I never saw it at work, except on TTY frames. > > We can make it work everywhere. Is that not an improvement? > >> But then Windows >>doesn't have SIGIO, it emulates that. Maybe that's the reason. > > SIGIO isn't the reason. The reason force quit doesn't work is the way it's > implemented. We can implement it better. That's my proposal, if you'd like > to consider it in more detail. > >>> >> On your Emacs, you can set N to one and T to zero. >>> > >>> > If read-event still returns a keyboard input event when C-g is >>> > pressed, I don't see how N = 1 would work. Can you describe how it >>> > would work? >>> >>> It wouldn't. Such a setting would prevent read-input returning C-g. >>> That shouldn't be the default. >> >>Sorry, I don't understand. If N = 1, what will read-event do when the >>user presses C-g while inside read-event? > > If N=1, it will quit after a single C-g. Specifically, it will raise a quit > signal. It will raise this signal instead of returning normally. It will not > return it as C-g to Lisp. If N=1, all the Lisp level input reading > functions, including read-key-sequence, will interpret a single C-g as quit. > >> Will it return the input >>event C-g, or will it quit? I thought your changes make read-event >>always return the input event, was I mistaken? > > You're asking about the N=1 case. I'm not proposing that N=1 be the default. > > For all values of 1 <= N <= M, I'm specifically proposing: > > When inhibit-quit is nil: > > #quits in [1,N-1]: event reading functions interpret C-g as an event called > \?C-g, aka the number 7. They return this event without quit-flag set. > > #quits in [N, infinity): event reading functions interpret C-g as > a quit. They do not return. They end by calling Fsignal with quit > error symbol. > > When inhibit-quit is non-nil: > > #quits in [1,N-1]: same as above > > #quits in [N,M-1]: return \?C-g with quit-flag set > > #quits in [M, anything): exit nonlocality by calling Fsignal with quit error > signal, effectively ignoring inhibit-quit. Print a message saying we've > done so. > > If debug-on-quit is set, we enter the debugger when the above table says the word "Fsignal". > > If throw-on-input, we raise quit on any input event whatsoever, never > returning to Lisp, no matter the value of #quits, N, or M. > > My proposal, by the way, does not change the meaning of quit-flag. > > If you find the above proposal unacceptable, can you please point to > a specific behavior it encodes and talk about what you'd rather it > do differently? > > Assume we can reliably detect #quits, please. I'm happy to talk about *how* > we detect repeated C-g, but the mechanism by which we do is independent of > rhe policy we want. > >>> >> We can customize thresholds for general behavior, but I don't think we >>> >> should not have preferences that alter the operation of fundamental >>> >> Emacs primitives. You couldn't add a preference that made if regard 0 >>> >> as well as nil as false, would you? >>> > >>> > Why not? If it helps debugging, we could definitely do that. > > In the exceedingly rare case that it is important to allow one C-g instead > of C-g C-g C-g to break out of an read-event or read-key-sequence loop (and > I have never seen one not deliberately constructed) users can customize N to > be one. I anticipate exactly zero people going that, but if you want the > knob, we have it. > >> We >>> > already have --enable-checking, which changes how some primitives >>> > work, in a very real sense. > > I'm not aware of any interface contracts that checking changes. What might those be? > >> As long as the feature is for debugging >>> > Emacs, anything useful goes, IMO. >>> >>> Because when you add a user option, people expect code you write to >>> operate under any value of that option, increasing implementation >>> complexity because you have to account for the _possibility_ someone >>> might operate in a certain way. >> >>No, people need not expect the code to operate the same under those >>special debugging-oriented values. We already have such features: >>debug-on-error = t might well cause some command cease working >>normally, and similarly condition-case-unless-debug > > Because I don't think this debugging mode is needed in any real world > scenario. Nobody I've seen infloops on read event outside a specially > crafted scenario. > > But if you want the knob to enable it, the knob is there in my proposal. Set > N=1. If you set N=1, then *both* read-event and read-key-sequence will quit > the first time you press C-g > >>So I think you are bothered by a problem that doesn't need to be >>solved. >> >>> >> >>> Maybe a compromise would be to continue the arms race and downgrade C-g >>> >> >>> to normal input, C-g C-g C-g to a quit, and require even more C-g's for >>> >> >>> a force-quit? >>> >> >> >>> >> >> That's also possible, though less desirable: counting C-g presses when >>> >> >> you are desperate is not easy and we cannot rely on users to do that >>> >> >> reliably. >>> >> > >>> >> > And we'd need a way to detect when a quit is handled (however we define >>> >> > "handled") so we could reset force_quit_counter. Not a trivial change. >>> >> >>> >> You don't. You just upgrade any quit that happens under the N and T >>> >> threshold above. >>> > >>> > I'm skeptical that we will be able to count C-g presses so as to >>> > reliably differentiate between double or triple press and two or three >>> > separate C-g presses. >>> >>> There is logically no difference between these two concepts. A double >>> keypress *is* two keypresses in a certain window of time. What other >>> concept could the combination of the words "double" and "press" convey? >> >>I don't understand what you are saying here. Yes, there's no logical >>difference between these, which is why I'm saying that reliably >>detecting "double C-g" is a challenge. We already have that with >>double-mouse. The difference between double-mouse and "double C-g" is >>that with the latter you cannot afford low reliability: when you want >>to quit, you want to do it immediately, because the runaway operation >>you want to interrupt could be harmful. > > I'm honestly not sure what reliability problems you're talking about. We > count the C-g key presses since we last entered the command loop and since > T milliseconds ago. If you say T to be a month and N=2 then if you're in > a read-event or read-key-sequence loop, press C-g once, suspend your > computer for a day, and press C-g again, we'll interpret the second C-g as > a quit and break out of the loop. > > Can you please give me some specific and concrete scenarios you have in mind > that might clarify these reliability issues you're talking about? > >>> > Different machines and OSes, and different >>> > system loads, can make it nigh impossible to do reliably. And that's >>> > _bad_, because when I want something interrupted right away, I don't >>> > want or even cannot try again and again and again until it works. >>> >>> Then define a separate key that means _only_ quit and that cannot be >>> bound to a regular command. C-g can't be that command without breaking >>> existing code. >> >>It's too late to define a separate key _instead_ of C-g. We could >>define a separate key _in_addition_ to C-g, but that doesn't solve the >>problem: people have C-g hardwired into their muscle memory, and it >>will take a lot of time for them to re-learn. Meanwhile, we get bug >>reports about C-g not working like it did before. > > No, we didn't get a bug report. We got a specially constructed program that > exercised a beneficial behavior change and called it a bug. I've yet to see > a real world problem. The person who constructed that program complained > that a loop that could be quit before was unquittable now. I am trying to > explain that it will, in fact, be quittable. > >>So minimizing the behavior changes is still a requirement, even if we >>add another key. And that's before we even consider what other key >>could serve that purpose, which is not a trivial problem to solve >>portably > > I'm not talking about adding another quit key. That's not the right > solution. I don't see a real world scenario in which multiple C-g doesn't > work well enough, and we have, what, decades of experience with this > mechanism on TTYs? Why is taking the force quit mechanism, fixing its > reliability issues, and generalizing it to GUIs suddenly a problem? > >>> Treating repeated C-g presses made in a reasonable window of time within >>> the scope of a single command in such a way that we're almost certainly >>> not confusing this series of keystrokes with C-g-as-command input solves >>> the problem. >> >>That's possible, but it is not the best alternative IMO, for the >>reasons I explained. > > I've yet to see you propose a different solution. All I've seen is > resistance to change whether it's beneficial or not. > > My proposal allows you to interrupt any Lisp program. In every real world > scenario, you can interrupt with one C-g. In pathological cases, you can > interrupt by pressing C-g multiple times. This mechanism is reliable. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 15:51:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.1749829846542 (code B ref 78737); Fri, 13 Jun 2025 15:51:04 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:50:46 +0000 Received: from localhost ([127.0.0.1]:48527 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ6fy-000084-7s for submit@debbugs.gnu.org; Fri, 13 Jun 2025 11:50:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49240) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ6fn-000051-TA for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 11:50:38 -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 1uQ6ff-0007Vg-Ug; Fri, 13 Jun 2025 11:50:25 -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=ZxHDfjqzsdIK597SErE2Oo4yD2bb3ft4gDnyoveGYgM=; b=Ep7+xt6N99iU KNZ9G/+kh3yKrFIjB4v749NR/EV86HlnqnxihpRyfWmyoVwIRES6HPnIwN4nWpGaGo9pVd0zKnEvk PrK0IL85J5hIKa33Dn4/ZEkB8LkzJuX+jjC/ZxmTDgIp9BK9zMPxQhGc5bpGQtR2KOpW4U90iaQoA sbLV1lBEzHscOe6YbonV5YatEuUjW7sDW4bpOmSh+bon78X3CBjYEiFyLorCTAom0/+r51RaToa37 qFa2pIXIY7A2P5bffMbikPgSgiPNJJAxMTXMjM27RpD6M+juQGbeSli4LxeEHcPYoN4euQ9vqrKqu LIYW4r7PJcMkD/zlXHbUwA==; Date: Fri, 13 Jun 2025 18:50:10 +0300 Message-Id: <861prnej4d.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Fri, 13 Jun 2025 07:48:54 -0700) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86tt4kdw7r.fsf@gnu.org> <86ecvneuut.fsf@gnu.org> <8A57564E-70F3-49F6-8D77-1C947087DF8C@dancol.org> <86cyb7em26.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Fri, 13 Jun 2025 07:48:54 -0700 > From: Daniel Colascione > CC: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > > On June 13, 2025 7:46:41 AM PDT, Eli Zaretskii wrote: > >> Date: Fri, 13 Jun 2025 04:49:21 -0700 > >> From: Daniel Colascione > >> CC: pipcet@protonmail.com, monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > >> > >> > >> > >> On June 13, 2025 4:36:42 AM PDT, Eli Zaretskii wrote: > >> >> From: Daniel Colascione > >> >> Cc: Pip Cet , monnier@iro.umontreal.ca, > >> >> 78737@debbugs.gnu.org > >> >> Date: Fri, 13 Jun 2025 00:53:38 -0700 > >> >> > >> >> > If you are talking about a GUI session, then IME the 'emergency exit" > >> >> > procedure isn't reliably working in that case, and I'm not sure the > >> >> > implementation intends to support that. I always knew that it's only > >> >> > reliably working on TTY frames. > >> >> > > >> >> > Or are you talking about the effect of the changes on the branch? > >> >> > >> >> FWIW, the purpose of my N-times-in-T-milliseconds-within-one-command > >> >> formulation of emergency exit is to get the mechanism working reliably > >> >> in all cases. > >> >> > >> >> I can definitely type 4-5 C-gs in a GUI Emacs (well, NS, but I recall > >> >> PGTK being similar?) and not have Emacs quit. If I mash C-g, it > >> >> sometimes does, and sometimes doesn't. > >> >> > >> >> Right now, the logic is this: > >> >> > >> >> { > >> >> /* Request quit when it's safe. */ > >> >> int count = NILP (Vquit_flag) ? 1 : force_quit_count + 1; > >> >> force_quit_count = count; > >> >> if (count == 3) > >> >> Vinhibit_quit = Qnil; > >> >> Vquit_flag = Qt; > >> >> } > >> >> > >> >> IOW, the first quit after clearing Vquit_flag resets the count to one. > >> >> Maybe that's why it isn't working reliably right now. If we reformulate > >> >> this mechanism not in terms of count == 3 (which is fiddly for all sorts > >> >> of reasons, since Vquit_flag can get reset) but in terms of the UX > >> >> directly --- N recent quits in T time in a single command --- we make > >> >> the whole thing more reliable. > >> >> > >> >> If you set T=infinity and N=3, you get the current force quit UX (modulo > >> >> my upgrade-before-disabling-inhibit-quit thing), just more reliably, and > >> >> you can break out of arbitrary Lisp code. > >> > > >> >I suggest to leave the emergency exit feature alone for now, and focus > >> >on the interruptibility of Lisp programs. > >> > >> That *is* the interruptabiltity of Lisp programs.l > > > >No, not in my book. A Lisp program should be interruptible without > >killing the Emacs session. "Emergency exit", OTOH, kills the Emacs > >session. > > Maybe we're talking past each other? I'm not proposing anything that automatically kills Emacs. I'm not sure what would have given you the impression we were talking about killing Emacs. I was talking about "emergency exit", and you responded to that, that's what gave me the impression. Emergency exit, as its name implies, exist the Emacs session. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 15:59:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498303135469 (code B ref 78737); Fri, 13 Jun 2025 15:59:05 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:58:33 +0000 Received: from localhost ([127.0.0.1]:48544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ6nY-0001Q0-MF for submit@debbugs.gnu.org; Fri, 13 Jun 2025 11:58:33 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:54388) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ6nL-0001Ns-Im for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 11:58:28 -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=T0fX6mRSgW7bIOO5bauvxzXiiRKYoqrxE7r9TyRhUBM=; b=aeFVJaSNpXG+NgD3KywGJrm67B w9qor1ppB2h/20f8V6SpYpE+pK3YjePpwlCr9QfFt6ZeHMhJ0Uw8PBrdxZz6qRtROdLr3HU3K1q8F sFQFa/qZsJwTdI4J42/9TCCVOzzcceIZzMm8kMsziKK1tuJuPkZMTPgwXgmWqEk16NoVLHPTVvN13 Tj5K+3yludbkPQ4zZ4IVdWy0OEpIzLWFBCbFlnO3VL36kTH6bKQhbjBNzcDTf7eN7oLnBNQ/e28MU joohyNbRPaPjiMnfS+ilXdO7zLIcAAY+XTxBBGmO0CzGSrpfPYRpnsuJ6UUArgtkVeS8CC3AuCrA6 0MQQ83aA==; Received: from [164.86.9.12] (port=58595 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 1uQ6lo-00BuHR-1G; Fri, 13 Jun 2025 11:56:45 -0400 Date: Fri, 13 Jun 2025 08:55:08 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <861prnej4d.fsf@gnu.org> References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86tt4kdw7r.fsf@gnu.org> <86ecvneuut.fsf@gnu.org> <8A57564E-70F3-49F6-8D77-1C947087DF8C@dancol.org> <86cyb7em26.fsf@gnu.org> <861prnej4d.fsf@gnu.org> Message-ID: <977B42F4-1598-4347-B3B4-479A496B21A5@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 13, 2025 8:50:10 AM PDT, Eli Zaretskii wrote: >> Date: Fri, 13 Jun 2025 07:48:54 -0700 >> From: Daniel Colascione >> CC: pipcet@protonmail=2Ecom, monnier@iro=2Eumontreal=2Eca, 78737@debbug= s=2Egnu=2Eorg >>=20 >> On June 13, 2025 7:46:41 AM PDT, Eli Zaretskii wrote: >> >> Date: Fri, 13 Jun 2025 04:49:21 -0700 >> >> From: Daniel Colascione >> >> CC: pipcet@protonmail=2Ecom, monnier@iro=2Eumontreal=2Eca, 78737@deb= bugs=2Egnu=2Eorg >> >>=20 >> >>=20 >> >>=20 >> >> On June 13, 2025 4:36:42 AM PDT, Eli Zaretskii wrot= e: >> >> >> From: Daniel Colascione >> >> >> Cc: Pip Cet , monnier@iro=2Eumontreal= =2Eca, >> >> >> 78737@debbugs=2Egnu=2Eorg >> >> >> Date: Fri, 13 Jun 2025 00:53:38 -0700 >> >> >>=20 >> >> >> > If you are talking about a GUI session, then IME the 'emergency= exit" >> >> >> > procedure isn't reliably working in that case, and I'm not sure= the >> >> >> > implementation intends to support that=2E I always knew that i= t's only >> >> >> > reliably working on TTY frames=2E >> >> >> > >> >> >> > Or are you talking about the effect of the changes on the branc= h? >> >> >>=20 >> >> >> FWIW, the purpose of my N-times-in-T-milliseconds-within-one-comm= and >> >> >> formulation of emergency exit is to get the mechanism working rel= iably >> >> >> in all cases=2E >> >> >>=20 >> >> >> I can definitely type 4-5 C-gs in a GUI Emacs (well, NS, but I re= call >> >> >> PGTK being similar?) and not have Emacs quit=2E If I mash C-g, i= t >> >> >> sometimes does, and sometimes doesn't=2E >> >> >>=20 >> >> >> Right now, the logic is this: >> >> >>=20 >> >> >> { >> >> >> /* Request quit when it's safe=2E */ >> >> >> int count =3D NILP (Vquit_flag) ? 1 : force_quit_count + 1; >> >> >> force_quit_count =3D count; >> >> >> if (count =3D=3D 3) >> >> >> Vinhibit_quit =3D Qnil; >> >> >> Vquit_flag =3D Qt; >> >> >> } >> >> >>=20 >> >> >> IOW, the first quit after clearing Vquit_flag resets the count to= one=2E >> >> >> Maybe that's why it isn't working reliably right now=2E If we re= formulate >> >> >> this mechanism not in terms of count =3D=3D 3 (which is fiddly fo= r all sorts >> >> >> of reasons, since Vquit_flag can get reset) but in terms of the U= X >> >> >> directly --- N recent quits in T time in a single command --- we = make >> >> >> the whole thing more reliable=2E >> >> >>=20 >> >> >> If you set T=3Dinfinity and N=3D3, you get the current force quit= UX (modulo >> >> >> my upgrade-before-disabling-inhibit-quit thing), just more reliab= ly, and >> >> >> you can break out of arbitrary Lisp code=2E >> >> > >> >> >I suggest to leave the emergency exit feature alone for now, and fo= cus >> >> >on the interruptibility of Lisp programs=2E >> >>=20 >> >> That *is* the interruptabiltity of Lisp programs=2El >> > >> >No, not in my book=2E A Lisp program should be interruptible without >> >killing the Emacs session=2E "Emergency exit", OTOH, kills the Emacs >> >session=2E >>=20 >> Maybe we're talking past each other? I'm not proposing anything that au= tomatically kills Emacs=2E I'm not sure what would have given you the impre= ssion we were talking about killing Emacs=2E > >I was talking about "emergency exit", and you responded to that, >that's what gave me the impression=2E Emergency exit, as its name >implies, exist the Emacs session=2E Ah, I was reading it as exiting the *current operation* and returning to t= he command loop --- a synonym for emergency quit=2E=20 I From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 16:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498306218729 (code B ref 78737); Fri, 13 Jun 2025 16:04:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 16:03:41 +0000 Received: from localhost ([127.0.0.1]:48571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ6sW-0002Gi-5A for submit@debbugs.gnu.org; Fri, 13 Jun 2025 12:03:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58774) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ6sM-0002G1-QR for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 12:03:37 -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 1uQ6sG-0000VV-CK; Fri, 13 Jun 2025 12:03:24 -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=m/blx5DiHtz94j4pzK2/Fz0+oGoWjkDeWi+GydHzOLI=; b=WYnhmZ9NqZ1s GOFB9uqpUTLOXOWGLpwnMlcWic4ETllRdsmg49PHMD8oIgDQYvWfiA+HeYDTPSv0tnMKROSZdtV4X L81ObzfazXP2y6sGnxl59oJ/XKOqcEioHGA6yLYhWR7Tjql8h9G3lHn5ga0n3ZDaVeJu6BZK2f7Xh p4cB8EKdQBrvJBlbRDnlC4tI/44ZrNPc8uAfzh7Sr6xse3y3cQvn42Vmf1zvWaShBLnlfsjAQAhyN u8BrNMhr2/jR02yt2E6IcrcrdwejmOTQKUbBDOmrayDGX7fcTBGBPywIDrR4CDQf95nEDXkgrKQwS 5fxACsUBlK3a0indw9UBTw==; Date: Fri, 13 Jun 2025 19:03:21 +0300 Message-Id: <86y0tvd3xy.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Fri, 13 Jun 2025 10:51:37 -0400) References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> X-Spam-Score: -2.3 (--) 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 (---) > From: Stefan Monnier > Cc: Daniel Colascione , 78737@debbugs.gnu.org, Eli > Zaretskii > Date: Fri, 13 Jun 2025 10:51:37 -0400 > > > Making > > > > (while t (read-event)) > > > > infloop without being able to quit is a bad idea. We shouldn't do it. > > I don't find this terribly problematic, If you think of what that loop > means it *is* a "please shoot me in the foot" kind of thing. > > I agree that not being able to escape is a problem, but it's not the > only way to get into such trouble. IOW I think it just gets us back to > the fact that we need an "emergency quit" for bugs (which `kill -USR2` > can sometimes provide, tho it's not a quit per-se). What I asked, and still didn't get an answer to, is at what point does a program that calls read-event becomes interruptible by a single C-g, after the changes on the branch? The above loop is not interruptible, but Daniel says that his proposal allows interrupting Lisp programs, just not silly programs such as the one above. So if we start from the above silly program, and add to it some meaningful processing of the event read by read-event, at what point does such a program become interruptible by a single C-g? Later responses by Daniel seem to indicate that the answer is "never". It seems like his proposal is to change the behavior of C-g such that to interrupt a Lisp program the user will need two or more C-g presses (with the number customizable) during some predefine time interval. Is that understanding correct? If it is, then what will a single C-g produce? will it _never_ cause a quit? If my understanding above is correct, then this is a significant change in behavior, and it is not yet implemented on the branch. I would suggest to discuss this change in behavior on emacs-devel before we decide to make the change (perhaps even before it is implemented, to prevent waste of development efforts in case the proposal is voted down). Whether we need an "emergency quit" (whatever that means) is a related, but separate question. Currently, what we have is the "emergency exit", which doesn't quit, but kills the session (with or without a core dump), and IME it doesn't work reliably in GUI sessions. Again, this is IMO a separate feature and a separate discussion. The discussion about what a single C-g does and how to interrupt Lisp programs using C-g is much more important and therefore much more complicated. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 16:06:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498307069331 (code B ref 78737); Fri, 13 Jun 2025 16:06:03 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 16:05:06 +0000 Received: from localhost ([127.0.0.1]:48595 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ6tp-0002Pq-AT for submit@debbugs.gnu.org; Fri, 13 Jun 2025 12:05:04 -0400 Received: from mail-10631.protonmail.ch ([79.135.106.31]:62971) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ6ti-0002Nc-Ch for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 12:04:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749830687; x=1750089887; bh=UBoHMoKZDfhqifnBzAatmPAji5lSbOrMv8BwR8RUeQo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=K0f8Bqdz2jPYqw8zkuDFYNk6Ld1Gdaj5MUAPTB8O/BG4BedlLeXP0M4SaEc/n2E6B JZq9T6Iu6GIzlXIJ2P/Fytwcp/qX7R1eFjT1sah1TwZ5Q5SUhUCIDaL8kjcbQw78O1 BUQmWTwHdreuqMntaNiTtKN++eUxbPMWj8LesruIRxwdUtfdcAF30Uq+gofVhuODsc dR+381FeDJclJ8gxHKIITFWbQIinxyAoWTYRGgMjme41wfnyAyTH5luTVk9LtglelB ReOAs6hqs4tuCQrcY4KhBl7y1VhtU3kMb9Uq0HjwQy3ZlwRAJBH0PdZWNJuscIoFnA /9JO5G4A0rv9w== Date: Fri, 13 Jun 2025 16:04:41 +0000 From: Pip Cet Message-ID: <87tt4jwru6.fsf@protonmail.com> In-Reply-To: References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <875xh21f2w.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 96487154fb366f71505b3eaeb5cd942d3bb434dc MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Stefan Monnier" writes: >> - ;; FIXME: we should not read-event here at all, because it's much t= oo >> - ;; difficult to reliably "undo" a read-event by pushing it onto >> - ;; unread-command-events. >> - ;; For bug#14782, we need read-event to do the keyboard-coding-syst= em >> - ;; decoding (hence non-nil as second arg under POSIX ttys). >> - ;; For bug#15614, we need read-event not to inherit-input-method. >> - ;; So we temporarily suspend input-method-function. >> - (let ((read (let ((input-method-function nil)) >> - (read-event nil t seconds)))) >> - (or (null read) >> -=09 (progn >> - ;; https://lists.gnu.org/r/emacs-devel/2006-10/msg00394.htm= l >> - ;; We want `read' appear in the next command's this-command= -event >> - ;; but not in the current one. >> - ;; By pushing (cons t read), we indicate that `read' has no= t >> - ;; yet been recorded in this-command-keys, so it will be re= corded >> - ;; next time it's read. >> - ;; And indeed the `seconds' argument to read-event correctl= y >> - ;; prevented recording this event in the current command's >> - ;; this-command-keys. >> -=09 (push (cons t read) unread-command-events) >> -=09 nil)))))) >> + (not (if throw-on-input >> + (sleep-for seconds) >> + (while-no-input (sleep-for seconds))))))) > > I'm not sure this will wake up on the same events (i.e. whether its > notion of what is "not a real input event" is the same). `sit-for` has > seen several iterations because of "corner cases", so I wouldn't be > surprised to bump into regressions, but I agree that it would be nice to > "align" the notion of "relevant" events used by `sit-for` with that used > by `while-no-input`. > [ IIRC part of the differences are the events handled by > `special-event-map`. ] > > Note also that I'm not sure `sleep-for` will actually do what we want > here (does it run process filters and timers? And update the display > accordingly?). You're right, there are differences (such as the hourglass displaying in one case but not the other, it seems). No obvious way to call wait_reading_process_output with precisely the right parameters. Let's drop this one for now. Inhibit-quit and quitting before rather than after removing an event from the queue should still both fix the original problem, if that's what we decide to do for now. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 16:12:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983107313213 (code B ref 78737); Fri, 13 Jun 2025 16:12:06 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 16:11:13 +0000 Received: from localhost ([127.0.0.1]:48623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ6zm-0003Qk-FC for submit@debbugs.gnu.org; Fri, 13 Jun 2025 12:11:12 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:61998) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ6zi-0003P4-FS for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 12:11:07 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CE146441578; Fri, 13 Jun 2025 12:10:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749831059; bh=eyCZxwinNIvWLO8Wd6mOJzOAdFiSPFy/6QF11LGiSmA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=IauFEX57bFrZS0l4KX3iIYJqV/ANqcY+BIL4B16gZEYLLwUZQYQsx2x6pJ91fddHs 6vl9PJoY0jpnbsZ8nhk7ndx7K+wA1lP4T+2s1UeL5oC2XUWIAeQ0fvBqLV2/cyWvq7 PtZTkO8gchmkzSJnrGwPdEQIi8KhBGCUnycuI3fqCGmrQ6UYnEa20rB00tLu2nMTY+ bsrnVuG9s6FTftTnFvAyPldK4k3bQv3rtsgRCHMbfytJRGjVUc24BghxDCLZOhxCMQ hd2QnZ6n6TxBxIyvaObYSHV1TpQuYbV6JFWKIt9Wh3soJJaiD4zXEqKQpuPalP7IFP xeepjXSIuZhmw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EF7E444155C; Fri, 13 Jun 2025 12:10:58 -0400 (EDT) Received: from asado (unknown [130.159.220.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BC9AE12068E; Fri, 13 Jun 2025 12:10:57 -0400 (EDT) From: Stefan Monnier In-Reply-To: <48D49344-799D-4680-A49C-373282B4F90B@dancol.org> Message-ID: References: <87ikl42c4l.fsf@protonmail.com> <86jz5jg8p1.fsf@gnu.org> <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <48D49344-799D-4680-A49C-373282B4F90B@dancol.org> Date: Fri, 13 Jun 2025 12:10:55 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.000 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >>Maybe `kill -USR2` would work better? > Thanks for reminding me to mention SIGUSR2. We'll treat it like #quits >= M. USR2 is used to jump into the debugger (from which we can jump back to top-level if we want), so it's only like `quit` in the sens of `debug-on-quit` but not in terms of exiting the current execution. > That's what I'm proposing. [ Yeah, I read that later. Thanks. ] Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 16:15:10 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983128515106 (code B ref 78737); Fri, 13 Jun 2025 16:15:10 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 16:14:45 +0000 Received: from localhost ([127.0.0.1]:48649 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ73A-0003vC-UB for submit@debbugs.gnu.org; Fri, 13 Jun 2025 12:14:44 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:50066) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ735-0003uD-3C for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 12:14:38 -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=m8EpofUK8FuZ2o8Mj845jAL8mHNxtY0dlW7zkNl+gUI=; b=RoCaNAGK3Pta6e1Yg0b6UjNtDp wEgKVvzji8HjVzDRcFjMLex66mSMp015psEJHHaQW+JNr6xmu/Hs0F7h4i5SmBbj1l4ridev9c4kX /dFU5+2yxCIW2bPvuEjXE+mCgvoPLvG+V1zISm1x7rqHoPs8eY5S3wP9jvKyaLiVZ1psuTsWEfePf QZ34wB2c8uU5ePnRP/XWGnhranKwus5OIAYUZethhDIt9KU80M9FDPnNwHB44nNpQu3JhNT+5AO7h PBKHdy23Hxrom9fMR13BHn8R6NksBP2KyqYhZQephAtrBoB3gmjqv4PvEWpEPe4X+DmXX5DpipWVe f8RonBjQ==; Received: from [164.86.9.12] (port=17378 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 1uQ71e-00BuZD-38; Fri, 13 Jun 2025 12:13:07 -0400 Date: Fri, 13 Jun 2025 09:14:20 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <86y0tvd3xy.fsf@gnu.org> References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> Message-ID: <9EF7F59A-8131-4EB5-92B5-D7C805434C59@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 13, 2025 9:03:21 AM PDT, Eli Zaretskii wrote: >> From: Stefan Monnier >> Cc: Daniel Colascione , 78737@debbugs=2Egnu=2Eorg= , Eli >> Zaretskii >> Date: Fri, 13 Jun 2025 10:51:37 -0400 >>=20 >> > Making >> > >> > (while t (read-event)) >> > >> > infloop without being able to quit is a bad idea=2E We shouldn't do = it=2E >>=20 >> I don't find this terribly problematic, If you think of what that loop >> means it *is* a "please shoot me in the foot" kind of thing=2E >>=20 >> I agree that not being able to escape is a problem, but it's not the >> only way to get into such trouble=2E IOW I think it just gets us back = to >> the fact that we need an "emergency quit" for bugs (which `kill -USR2` >> can sometimes provide, tho it's not a quit per-se)=2E > >What I asked, and still didn't get an answer to, is at what point does I believe I answered your question at length in and specifically addre= ssed the question above=2E I believe I'd addressed the subject several time= s before as well=2E Could you please take a look at the proposal before declaring these questi= ons unanswered? >a program that calls read-event becomes interruptible by a single C-g, >after the changes on the branch? The above loop is not interruptible, >but Daniel says that his proposal allows interrupting Lisp programs, >just not silly programs such as the one above=2E So if we start from >the above silly program, and add to it some meaningful processing of >the event read by read-event, at what point does such a program become >interruptible by a single C-g? > >Later responses by Daniel seem to indicate that the answer is "never"=2E >It seems like his proposal is to change the behavior of C-g such that >to interrupt a Lisp program the user will need two or more C-g presses >(with the number customizable) during some predefine time interval=2E >Is that understanding correct? No, that is not correct, and I've said so many times=2E I'm not sure what = I could say to increase clarity=2E Outside contrived corner cases, the only difference users will notice is t= hat quitting works more reliably=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 16:19:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983151117552 (code B ref 78737); Fri, 13 Jun 2025 16:19:03 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 16:18:31 +0000 Received: from localhost ([127.0.0.1]:48659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ76n-0004YE-2Q for submit@debbugs.gnu.org; Fri, 13 Jun 2025 12:18:30 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:22777) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ76d-0004Vw-KQ for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 12:18:20 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9168C441589; Fri, 13 Jun 2025 12:18:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749831488; bh=O8lCc/cpU3Xuh1wuxhp+it75hAp+vR9StLR9l0IOc3Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=D5hS6ddK4Qe3gAnZtkrd1q4/LTK+cw+7NOKG+/82KauWONU4oapjeyDxvNgCWtcRJ 2UylRolltQo0K71PMQ1ZjQEMq0U8iJoK4QmzoYrf9LhjX16iFoAoe4D+FQBhBrfzlN GGrCnCdCb5t9xrHC6tOb88JbuknwEGTpO2grtMZdVtFUhAwheOXT+gd+WSuEjJxS0a 1UK6HZ8KxUrsJqc4zpo5PdIgyUeG2SBbdk4BwcLT0+KaSFIPjI5MuM8dN0E6pD5R9q 69hZ+S5kcMR1nLObycZ7F1kBMo3yjyZZcOvUrbZikpEik0890VMHc5+JH2sLk5Pz7u Itd6F7Q1Sk06g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 31EF5441510; Fri, 13 Jun 2025 12:18:08 -0400 (EDT) Received: from asado (unknown [130.159.220.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B14F1121138; Fri, 13 Jun 2025 12:18:06 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86y0tvd3xy.fsf@gnu.org> Message-ID: References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> Date: Fri, 13 Jun 2025 12:18:03 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.000 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > What I asked, and still didn't get an answer to, is at what point does > a program that calls read-event becomes interruptible by a single C-g, > after the changes on the branch? It's interrupted if the `C-g` occurs while running the code rather than while sitting inside `read-event`. For the tight `while t` loop, it's virtually never. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 16:23:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983177620729 (code B ref 78737); Fri, 13 Jun 2025 16:23:04 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 16:22:56 +0000 Received: from localhost ([127.0.0.1]:48670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ7B8-0005O1-I3 for submit@debbugs.gnu.org; Fri, 13 Jun 2025 12:22:55 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:38562) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ7B6-0005NT-Dz for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 12:22:52 -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=5xr537dkbMRcKrbaoUpdILkAkgAzU1PZ8p/NN9nR830=; b=IDowK3YP3rC85nAvTB2h/Kf16p TS/nqQotB5cU5yfVeIp+Tl6Xi3p68KVNQBKJhdgqM+Mz4n980q9h8ttVhDp5EnE2DeGX/GSoslS0z HtkqtNEVQ6bylXsMPDt2KU1BX9OXmeETNfRTlVWVhGXc+JhkgIVdL1jdq2B5e/2q7SXgLxSxoPXk7 zl4S0iJjb36UkRE6YXskupewoW9dmRl+x8YM3ckjC5J4kDvglmLai9bRyIP0Fyu0aPjBTfvPk0+VN SQabez6QyyguVr/+rxLjc4WjaTl/BD/gTbSKzez42w7k2WWat0B2TMyO3ez0xVtBfadpFhXhfOgsu 3qmpqUYQ==; Received: from [164.86.9.12] (port=62902 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 1uQ79g-00Buab-31; Fri, 13 Jun 2025 12:21:25 -0400 Date: Fri, 13 Jun 2025 09:22:21 -0700 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.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-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 June 13, 2025 9:18:03 AM PDT, Stefan Monnier wrote: >> What I asked, and still didn't get an answer to, is at what point does >> a program that calls read-event becomes interruptible by a single C-g, >> after the changes on the branch? > >It's interrupted if the `C-g` occurs while running the code rather than >while sitting inside `read-event`=2E For the tight `while t` loop, it's >virtually never=2E For clarity's sake, Stefan is describing what's in the branch right now an= d I'm describing what will be on the branch before it's ready for merging= =2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 17:34:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, dancol@dancol.org, Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983603031346 (code B ref 78737); Fri, 13 Jun 2025 17:34:04 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 17:33:50 +0000 Received: from localhost ([127.0.0.1]:49106 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8Hm-00089V-5Z for submit@debbugs.gnu.org; Fri, 13 Jun 2025 13:33:50 -0400 Received: from mail-10631.protonmail.ch ([79.135.106.31]:24599) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8Hh-00088q-W0 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 13:33:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749836018; x=1750095218; bh=HQgrvPd2Rv5RdMUuqa5DKNpWvFHrIYHv8cw/ypavCTs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=ApfJxNB7rdetpJETebrM+oXSMKEIfoXWqpLUfmSKKyRm8e7im/InT3O58pKto3rwv dwvObFOlmM66DHjNExPJu3BojK7os1vb0oe2Nm0i9GYMXrk2h6eRjTgpbIAREW3VOv yMLIK4kVDcw9hEdnpKWcJgfEy7k2+TmTI3N0mydvw+KRE6bB1q+bAJTBSwdLHZjFkD iEHMfW4VcRVpQX1eI0M9HFffvxmTTwuRiL5/Zx7ntmyqWT5EKmxefu+ut9UgUDihCd g5bYjwhAlyUaoGUg+cPQ7Xpv+nh6NJaYj1LyS3csA+W/7P6MMLi2CwyuO6gOggFLX5 Amirc3q7NuQnQ== Date: Fri, 13 Jun 2025 17:33:33 +0000 From: Pip Cet Message-ID: <87o6urwnq0.fsf@protonmail.com> In-Reply-To: <86y0tvd3xy.fsf@gnu.org> References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 309e37df20688d660b97b501160a70f57204958a MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Eli Zaretskii" writes: > Whether we need an "emergency quit" (whatever that means) is a > related, but separate question. Currently, what we have is the > "emergency exit", which doesn't quit, but kills the session (with or > without a core dump), and IME it doesn't work reliably in GUI > sessions. I think the behavior of C-g C-g C-g is, as you describe, very different in GUI-only sessions and in sessions with a terminal frame: if there is a terminal frame, we offer to auto-save and kill the session (there is an option to continue the session, but I don't know whether it works); if there isn't, we set inhibit-quit to nil and quit-flag to t and hope for the best. (This description simplifies things somewhat; handle_interrupt has the gory details). We don't even tell the user that if we modified inhibit-quit, there is a significant risk they just destroyed their session and that they have to restart Emacs. On the other hand, many places assume inhibit-quit doesn't change under them and don't react to such changes, so a C-g C-g C-g may do nothing; in this case, you usually don't get a second chance because of the force_quit_count > 3 behavior. > Again, this is IMO a separate feature and a separate discussion. The > discussion about what a single C-g does and how to interrupt Lisp > programs using C-g is much more important and therefore much more > complicated. I think both discussions are important, but they depend on each other in this way: I think improving C-g C-g C-g, a lot, is necessary *before* we put more blank bullets into C-g than there already are. In fact, it may be easier to think of it as replacing it by something somewhere between the current C-g and the current C-g C-g C-g. My suggestion is (Someone Else) coming up with a proposal for a good "C-g C-g" (which might involve a different key sequence entirely), implementing it, and then, only then, can we decide whether Daniel is right and single C-g should become a normal input event in more (Daniel's proposal) or all (my modification; this is not what Daniel proposed) situations. Or maybe we want to put the genie back in the bottle and make C-g mean "quit" again, in almost all situations, such as in transient mode. If C-g C-g (or the same functionality by any other name) works and works well, should we really let our muscle memory of using a single C-g for quit stand in the way of more consistent behavior, freeing C-g for ordinary use (it'd still mean something quit-like, a polite warning that you're about to hit C-g a second time)? We could even think of it as a way in which Emacs stabilized beyond the need for a two-keystroke quit key. But, right now, we can't reliably use C-g to quit Lisp programs; we can't reliably use C-g C-g C-g either; we can't *safely* use C-g C-g C-g either; and we can't use C-g as an ordinary input event with perfect safety (but we have code which, essentially, assumes CPUs are so fast now that we can get away with it in practice). (That last one may be fixable, and it needs fixing for the MPS branch.) Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 17:35:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983605131480 (code B ref 78737); Fri, 13 Jun 2025 17:35:05 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 17:34:11 +0000 Received: from localhost ([127.0.0.1]:49121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8I6-0008Bg-MD for submit@debbugs.gnu.org; Fri, 13 Jun 2025 13:34:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33014) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8I4-0008B6-Km for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 13:34:09 -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 1uQ8Hy-0004PH-J1; Fri, 13 Jun 2025 13:34:02 -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=mR590taL4Po+/UtDK+QvoW8YYOOMJlQYgxo2u4WBshQ=; b=pEAyPVXtVTux SMjTLmGhqM0MRcVmvAWXatSXetTsWusEGK7pGulZBKfJJe1EGyYMI2C0p24sxdZ/ERI5GN6c9ml2t M1pw7nkEfTVrLkWZSm1l5EBt5WncyV/M4APHcH/x7Y3Zzo6ljl/CYvc5RM0tm/AYFburTtBZUk4g+ DoQxiH+1GI8BBBaH6xhvgeoehx7XTTwtIPG6JJFrIAD6/TajbeOW0bh+CtEs1sYV/f4HRDUnpPpjS RH/K7R0ypcrv5dvX2Ik3APai8aWDTRcHLl/ZHwW+s1EjqUjAftamBDpJyTmq2ZrdOEjbVXDQ48Yh5 99inosJSr0GkGpewvaywiw==; Date: Fri, 13 Jun 2025 20:33:59 +0300 Message-Id: <86jz5ftuk8.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Fri, 13 Jun 2025 11:09:33 -0400) References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> <86y0twerm0.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Stefan Monnier > Cc: Daniel Colascione , 78737@debbugs.gnu.org, > pipcet@protonmail.com > Date: Fri, 13 Jun 2025 11:09:33 -0400 > > > Specifically, what I'm interested in is how come > > > > (while t > > (read-event)) > > > > cannot be interrupted by C-g, but you seem to be saying that > > > > (while t > > (let (evt (read-event)) > > (do-something-with evt))) > > > > _can_ be interrupted? > > Usually the `(do-something-with evt)` part will offer some way to end > the loop. How? If read-event returns the character 7, then the information about the fact that C-g was typed is lost by the time we get to the do-something-with part, no? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 17:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.1749836299592 (code B ref 78737); Fri, 13 Jun 2025 17:39:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 17:38:19 +0000 Received: from localhost ([127.0.0.1]:49196 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8M6-00009U-Iv for submit@debbugs.gnu.org; Fri, 13 Jun 2025 13:38:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57678) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8M2-000096-Aa for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 13:38:16 -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 1uQ8Lw-0004r6-Kz; Fri, 13 Jun 2025 13:38:08 -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=7GreQCbHwmSwJlhEDG4QA8D8fn46o3UvWR3K0J+3gB8=; b=FZae/AF0w6TJ FviiUQfAtaBVIq3brE5Sm42y1SeaiwC6RluXCPBAPyu4xnUZNAErVguRc6yNvcPvZ4Pq6MwZnikTc jxP1Y0iIUD5jN3fGDo1dY9ppSgFf7/IugsglX7btMBtdzkYxvoe7sjp8JRb1FTGbuZDojSFIzQNrQ rLbL/IGPsVSZADhdWMLv9W/4b3DwIHL4HE89UUQE470yeCCOMSj+YjX7s/79Y8tscbecaBFTtlyIB 7D3xt7UdUh1w3ujTRKfPTNWRlrIvrhs/qCa8LY1qdeMWinEqPK1JrT+xhNOJo+yadQ7rk6q1AGBA4 7Zg/0+9LnKmqHAvYXdhkZw==; Date: Fri, 13 Jun 2025 20:38:06 +0300 Message-Id: <86ikkztudd.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Fri, 13 Jun 2025 11:24:29 -0400) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Stefan Monnier > Cc: Daniel Colascione , 78737@debbugs.gnu.org, > pipcet@protonmail.com > Date: Fri, 13 Jun 2025 11:24:29 -0400 > > > We should start by agreeing that the capability of interrupting a > > running Lisp program is a real need. Are we in agreement about that? > > If not, let's first hear the arguments why not. > > It's a real need, but there's also a real need for some ELisp functions > to catch normal quits. So we can't have "normal quits" as the universal > answer to "interrupting a running Lisp program". What is a "normal quit"? And what other kinds of quit are there, and what are they? It sounds like not only do we disagree about some aspects of this, we don't even have a common terminology. > What we have instead is that "normal quit" should work to interrupt any > well-behaved ELisp programs, plus it should also work to interrupt most > other ELisp programs (IOW it shouldn't be hard to write well-behaved > ELisp code), but there has always been and will always be cases where we > need an "emergency quit" to interrupt some ELisp programs (and that > feature has been missing in GUI builds for a while). What is "emergency quit"? And if you are describing the current situation on the master branch, then the changes proposed on the branch still leave some programs not interruptible, just a few more. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 17:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498368744054 (code B ref 78737); Fri, 13 Jun 2025 17:48:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 17:47:54 +0000 Received: from localhost ([127.0.0.1]:49370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8VN-00013J-VQ for submit@debbugs.gnu.org; Fri, 13 Jun 2025 13:47:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41786) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8VL-000136-KS for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 13:47:52 -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 1uQ8VF-00067B-LT; Fri, 13 Jun 2025 13:47:45 -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=sJRDcpuHZKH9re9uNOFDCXidiJuK66/tkYUytPQMLRs=; b=WPSPnSOC8k9T z3v14CyBncRKDlT35AvHmPaaxRGOrZvHec/iVB4J0ZiSKFO4/tphOdxOXgCGR/+WWY8Tv7qwLQzZq IvFqeESrKflqAxTsNvZiKqwyG6/EgaZJXnMkEL8R5+8ehWBY3pq8QkoKJ7VGY6qjcIffxb+XO7LA5 VCwHHVIRsM+uZ8Qf/rkQs5P1q7t73qyoQO15/hMjB/KUxzynl3ln+YotT32DOi/TfvanOpKzPrKD7 9VAGD5tJ1e4nAxr7hOxS5jtaUmft5JdR4WCo1MTjzy7lytwUe3fwiflHWuSUseTD4ox3strPUImcK wvZrBzL5rnTVYNwt5Ho9og==; Date: Fri, 13 Jun 2025 20:47:43 +0300 Message-Id: <86frg3ttxc.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <9EF7F59A-8131-4EB5-92B5-D7C805434C59@dancol.org> (message from Daniel Colascione on Fri, 13 Jun 2025 09:14:20 -0700) References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <9EF7F59A-8131-4EB5-92B5-D7C805434C59@dancol.org> X-Spam-Score: -2.3 (--) 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: Fri, 13 Jun 2025 09:14:20 -0700 > From: Daniel Colascione > CC: pipcet@protonmail.com, 78737@debbugs.gnu.org > > On June 13, 2025 9:03:21 AM PDT, Eli Zaretskii wrote: > >> From: Stefan Monnier > >> Cc: Daniel Colascione , 78737@debbugs.gnu.org, Eli > >> Zaretskii > >> Date: Fri, 13 Jun 2025 10:51:37 -0400 > >> > >> > Making > >> > > >> > (while t (read-event)) > >> > > >> > infloop without being able to quit is a bad idea. We shouldn't do it. > >> > >> I don't find this terribly problematic, If you think of what that loop > >> means it *is* a "please shoot me in the foot" kind of thing. > >> > >> I agree that not being able to escape is a problem, but it's not the > >> only way to get into such trouble. IOW I think it just gets us back to > >> the fact that we need an "emergency quit" for bugs (which `kill -USR2` > >> can sometimes provide, tho it's not a quit per-se). > > > >What I asked, and still didn't get an answer to, is at what point does > > I believe I answered your question at length in and specifically addressed the question above. I believe I'd addressed the subject several times before as well. > > Could you please take a look at the proposal before declaring these questions unanswered? I did. My current understanding is that what you propose will cause some (most) programs to be interruptible with a single C-g, while some (in particular those which call read-event) will need two or more C-g to be interrupted. Is that correct? If this is correct, then we need to decide whether this inconsistency (one C-g vs several) is tolerable. > >Later responses by Daniel seem to indicate that the answer is "never". > >It seems like his proposal is to change the behavior of C-g such that > >to interrupt a Lisp program the user will need two or more C-g presses > >(with the number customizable) during some predefine time interval. > >Is that understanding correct? > > No, that is not correct, and I've said so many times. I'm not sure what I could say to increase clarity. Is the modified description above correct? If not, what is incorrect in it? > Outside contrived corner cases, the only difference users will notice is that quitting works more reliably. Thanks, but that doesn't answer my question, which is specifically about the effect of C-g on Lisp programs, whether they call read-event or don't call it. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 17:50:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498369464411 (code B ref 78737); Fri, 13 Jun 2025 17:50:06 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 17:49:06 +0000 Received: from localhost ([127.0.0.1]:49391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8WV-00018r-OH for submit@debbugs.gnu.org; Fri, 13 Jun 2025 13:49:05 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56664) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8WR-00017L-LI for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 13:49:01 -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 1uQ8WL-0006EI-FC; Fri, 13 Jun 2025 13:48:53 -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=WjNiVIvzP/i1YG90WlywpckCpAlFaLnZNgkI5u6SuVg=; b=bIsUscGTIhvH v4nEu1PLXA+CiV0iKvMsh7pkateuJ3ZETTdDMjMVZnnhSMiNv1/XX6w+lwvyccueliGoYV2jIVHNf WL8gsVFjs1WnYfpsqzpDuQvjzFU3lLsAfLqvmKo2tquZFlzQATL1EN2s5R82WM8NsVDhOxxvjouum kULOYkSCb0CpHMnjODUBoyyqtzjehM9NZqqjXVOh3CLK872a8993ZLZf0WxwLq649gsoHJueNK9Mt TJVFX2Tkk65OkqAwOWbs60uj8YMP6m9OUEsZGLwsChEZFsibc/UMj7re17a7ditEih1i6kOU9H30H 28QcBRE0xic5dEq2WPnoLA==; Date: Fri, 13 Jun 2025 20:48:49 +0300 Message-Id: <86ecvnttvi.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Fri, 13 Jun 2025 09:22:21 -0700) References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Fri, 13 Jun 2025 09:22:21 -0700 > From: Daniel Colascione > CC: pipcet@protonmail.com, 78737@debbugs.gnu.org > > On June 13, 2025 9:18:03 AM PDT, Stefan Monnier wrote: > >> What I asked, and still didn't get an answer to, is at what point does > >> a program that calls read-event becomes interruptible by a single C-g, > >> after the changes on the branch? > > > >It's interrupted if the `C-g` occurs while running the code rather than > >while sitting inside `read-event`. For the tight `while t` loop, it's > >virtually never. > > For clarity's sake, Stefan is describing what's in the branch right now and I'm describing what will be on the branch before it's ready for merging. And my question was bout the latter, not the former. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 18:01:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498376479174 (code B ref 78737); Fri, 13 Jun 2025 18:01:04 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 18:00:47 +0000 Received: from localhost ([127.0.0.1]:49653 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8hp-0002Np-J7 for submit@debbugs.gnu.org; Fri, 13 Jun 2025 14:00:47 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:50837) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8hl-0002MR-84 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 14:00:42 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7BA241000BC; Fri, 13 Jun 2025 14:00:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749837633; bh=xf02SfYBtsY38n7db+cqFPUy8kwls02tdggtx1ZaGMk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=b09fn5cBqfDxdUhPIjDjsXmFX5PxAJSZXIhxM3HHTk2g6NCRzxQHcyJKqdHLPs7Vk Gp6Ugbrelmy1eU0tBPKFZUQQLHVVCdNdbxg2d2XhMdjq6Pj5yHt/Pazj8M+YHczP1a C+LwvfMAPjuhelQv99gL37FvKGd3ISgSUewK3rUfTkc+y/rQfEPkECw9syhG4c7GoW FKqhHVXRv0IH9IRwhwfIkrnVqKw26mWzIHxdqXROo5co8oBWwCyBtLvSSFZyd3nwUh GqIVbsRix9hMOXp68BTxBIBMCSlNBEQjBYh02aoVkjL28Zpw5jWpebttZDEyMAgO8V aWqZlvX88RKtQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 996FE100034; Fri, 13 Jun 2025 14:00:33 -0400 (EDT) Received: from asado (unknown [86.53.241.66]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D1D4012044C; Fri, 13 Jun 2025 14:00:32 -0400 (EDT) From: Stefan Monnier In-Reply-To: Message-ID: References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> Date: Fri, 13 Jun 2025 14:00:31 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >>> What I asked, and still didn't get an answer to, is at what point does >>> a program that calls read-event becomes interruptible by a single C-g, >>> after the changes on the branch? >>It's interrupted if the `C-g` occurs while running the code rather than >>while sitting inside `read-event`. For the tight `while t` loop, it's >>virtually never. > For clarity's sake, Stefan is describing what's in the branch right now and > I'm describing what will be on the branch before it's ready for merging. I thought the difference was only in terms of "emergency quit", which I think is not what Eli referred to when he meant "interruptible". [ I suspect these kinds of differences of intended meaning are a significant part of the misunderstandings in this thread. ] Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 18:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, Daniel Colascione Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983805511598 (code B ref 78737); Fri, 13 Jun 2025 18:08:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 18:07:35 +0000 Received: from localhost ([127.0.0.1]:49785 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8oP-00030y-Ni for submit@debbugs.gnu.org; Fri, 13 Jun 2025 14:07:34 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29494) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8oL-0002zU-Nm for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 14:07:31 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1A6DF4415EB; Fri, 13 Jun 2025 14:07:24 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749838043; bh=CvQJ9jXhJNTdyaSrCgOEZvIxGaZqZzXJNboSqi0JtGI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=eINMdea/se5ehTI1Yi44w257vlL9GKrgaFrLf7m+VBOMAf/f36BTgo3mmqOkuaugS QFfnBDhh7HQpJIrx1fn6eDBD/K8XUUfPQ/sVCjDE887q24gu4NWrM7M40D3F7u8wLh zk5NVg5dFt0h2Oqxc2o30Zzus30V2E0e0D5JBf8XqwwPmUdZOPCMgT1Mx3+mPtvZ8u Gj+Dz7JCnkwEnAFp9lRIt0e0hyPHf6L4oakfvJQbhVFoVaBdEEyYZZtWRx+4bzpNok mkv01yAV9X8/7yW1ximnQskUh1TeoC1zKcggzNgjh67BOaqjtnl+Avagp3upQ6AZ7U uN/6Q0fS3HJWw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 262F94415C8; Fri, 13 Jun 2025 14:07:23 -0400 (EDT) Received: from asado (unknown [86.53.241.66]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5600D1206D0; Fri, 13 Jun 2025 14:07:22 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86frg3ttxc.fsf@gnu.org> Message-ID: References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <9EF7F59A-8131-4EB5-92B5-D7C805434C59@dancol.org> <86frg3ttxc.fsf@gnu.org> Date: Fri, 13 Jun 2025 14:07:20 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.601 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > My current understanding is that what you propose will cause some > (most) programs to be interruptible with a single C-g, while some (in > particular those which call read-event) will need two or more C-g to > be interrupted. Is that correct? I think so, tho only for *some* of those which call `read-event`. > If this is correct, then we need to decide whether this inconsistency > (one C-g vs several) is tolerable. That inconsistency already exists in various places, such as if you use `read-key`. I think what we need to decide is if the resulting overall behavior is better (e.g. easier to describe and less error prone), and if so, whether it's worth the incompatibility. Of course, we could also make the change more backward-compatible by renaming `read-event` to some new name and (re)defining `read-event` on top of that new function. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 18:15:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983849614319 (code B ref 78737); Fri, 13 Jun 2025 18:15:06 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 18:14:56 +0000 Received: from localhost ([127.0.0.1]:49990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8vX-0003it-Sl for submit@debbugs.gnu.org; Fri, 13 Jun 2025 14:14:56 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8604) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8vV-0003ih-ST for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 14:14:54 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 57C7D1000BC; Fri, 13 Jun 2025 14:14:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749838487; bh=LTfUDM+hyp8HOrSSdc3croFoWidJw8RQujpI0OL1e5E=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QsZAQlSiOmYQEDw91ng0yzDKDx4elJmmWJKjXzXniUpOTd/xUKxq9dXS0KLgcLWkx YLWYBpOjrWWkJ0Z7tQvFZ4ffmlthf9QNL1YAJ9rd7qw6Lo0GmCwGfI/sBD9nOLlD/p iy4KNo8ioMfyIJ7Ol105UJAo1pXarGIH+8Hp+rlf2kpCFrC8I5QiYNRZE/XYqrnFEd UjzLcleTbF/x4iwTG672FzbfIrHupPcr4cXqND9ujJaprcA8Ra9xSilYMuKMsqvdd9 VHBBQBB5065M0b0FmTdbDFMHfjTTpbHGNF4IDXh0IYPdkuzAxtIEs/Y/1rgSII/sRQ asx5X/ZmCf5mg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 57B1710002E; Fri, 13 Jun 2025 14:14:47 -0400 (EDT) Received: from asado (unknown [86.53.241.66]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A2BF9120607; Fri, 13 Jun 2025 14:14:46 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86jz5ftuk8.fsf@gnu.org> Message-ID: References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> <86y0twerm0.fsf@gnu.org> <86jz5ftuk8.fsf@gnu.org> Date: Fri, 13 Jun 2025 14:14:44 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> > (while t >> > (let (evt (read-event)) >> > (do-something-with evt))) >> > >> > _can_ be interrupted? >> >> Usually the `(do-something-with evt)` part will offer some way to end >> the loop. > > How? If read-event returns the character 7, then the information > about the fact that C-g was typed is lost by the time we get to the > do-something-with part, no? AFAIK that information is in `evt` and hence not lost. Usually `do-something-with` will look at `evt` and do various things depending on the key that was pressed and usually one of those options lets you end what you were doing. Some code may assume they don't need to explicitly abort when `evt` is 7 because they rely on the current behavior of `read-event`, but AFAIK that behavior is not completely reliable (e.g. it depends on `inhibit-quit` and sometimes timing), so if we want to encourage use of that feature we should try and make it more reliable. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 18:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983857815203 (code B ref 78737); Fri, 13 Jun 2025 18:17:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 18:16:18 +0000 Received: from localhost ([127.0.0.1]:50030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8ws-0003x9-6O for submit@debbugs.gnu.org; Fri, 13 Jun 2025 14:16:18 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48104) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8wr-0003wp-3O for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 14:16:17 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6CC0C4415EB; Fri, 13 Jun 2025 14:16:11 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749838570; bh=sXu5XPDAkjjl2aTqWlcMKXXPUVBLiWKe1DKPI7Wh8MI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=S8S5EtKex5WW/pWb5j8UKS3NbtpdoyYgzuRT9MHBeYrlqPjTQXL9wfFMNKBSTKAdW d+kfm131iN+BWrPQF3JrgrXA1oz0v7+18Cxo1e1aYkG4zPFiKJv0gkJPXz/Etb8kJ8 VwOoFHBGtlr4YPDlvUGvcQhq/IJY6Pln/cwx4JyRoEURjBrkz8G7CrwwOrUSikVfQI 2Yu/AIww6M7i/KeecM2lpqneN4NMTocq+obKT2vDM19fECsGh/PEgNCrcIARXn+zB2 PF3DLWo+QDSMZsjoFaMXsyH5n6c6+3aAdGR8xgwBSCvIhBdIE6W5XdkAXYvwiHhibO jUxcgwhp/P6Cg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 84E304414EE; Fri, 13 Jun 2025 14:16:10 -0400 (EDT) Received: from asado (unknown [86.53.241.66]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AE6F012068E; Fri, 13 Jun 2025 14:16:09 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86ikkztudd.fsf@gnu.org> Message-ID: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> Date: Fri, 13 Jun 2025 14:16:08 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.451 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > What is a "normal quit"? A single C-g. > What is "emergency quit"? Something like `C-g C-g C-g`, tho we don't have that implemented, currently, AFAIK. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 18:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983863615535 (code B ref 78737); Fri, 13 Jun 2025 18:18:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 18:17:16 +0000 Received: from localhost ([127.0.0.1]:50055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ8xl-00042S-NT for submit@debbugs.gnu.org; Fri, 13 Jun 2025 14:17:15 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60399) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ8xi-000413-5a for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 14:17:11 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 920B71000BC; Fri, 13 Jun 2025 14:17:04 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749838623; bh=5J6yrraFF5BuSuvNFDtmm0S6/OavEbvHuYk20lYUtyc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Zw2BsVWSFNY/g/aLnYsXvbr44rGeNscwbks4hBQHyVQAayevyeISCUYBM05LDnQOO 628FsyVoyMuuMgX29NmrtXRE86vjzma7y43UrOUG47yUVW+xirZ/EfD01zTERjV4pT TaWyKHwQU2m/ZFqVJ39zS+RFig8xNdJ6Y59mpIIztQN35KaU3JDYec5vqiUFp/Mg98 Z1uW+usqQ2i4kB3crojDP0ccGFkiEi+5qj/QVHaDD87fii+IpGqUnhmYfdbKT3r9PI UfirBnZwPXU48dyJpniPUhvvFPaBXT45udS9RWhYfdQ1HeS0ZQv9LK4v8O3HNYOeVz t5jGo8DHv0PKQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CDDB910002E; Fri, 13 Jun 2025 14:17:03 -0400 (EDT) Received: from asado (unknown [86.53.241.66]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 25BEE12034C; Fri, 13 Jun 2025 14:17:03 -0400 (EDT) From: Stefan Monnier In-Reply-To: Message-ID: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> Date: Fri, 13 Jun 2025 14:17:01 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> What is "emergency quit"? > Something like `C-g C-g C-g`, tho we don't have that implemented, > currently, AFAIK. I guess `kill -USR2` could count as well. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 18:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii , dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983912618171 (code B ref 78737); Fri, 13 Jun 2025 18:26:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 18:25:26 +0000 Received: from localhost ([127.0.0.1]:50248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ95h-0004j0-MC for submit@debbugs.gnu.org; Fri, 13 Jun 2025 14:25:25 -0400 Received: from mail-4322.protonmail.ch ([185.70.43.22]:20149) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ95e-0004dp-N5 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 14:25:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749839116; x=1750098316; bh=kmsVpgiJQ8Bwgi/Lps0YhO+egUhGkErWCosRyDuO4Tg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=M9f2Lme0TcCRt8/r6gdSbCwN6Er/BIZHfvg4BrAM/lu+HYiE6YFhv4P/YHigrpPiU SwhDWGkNPC6cupdswHl9gKTqR0lAq6KFHOybxL55v9Zqy8Mwf1kwpXtf4qEfdwH6dU 3Z9u/cmCWlxv55Eg76AjZMGUfdO34rL65dLeJXbZskaU+k3Z27QKwjqh9wg3i8tPZo mcVWNoA+PqAXYu9zm6oWZy2tq6DQ9FOwy9T8cubZdbuyjmcaurd343E6341+bJt4Wf 3ZybUvmHo60OqXMQ2sZIvZgJ2IDehZ9rg1iLb65eduZMnWoLr+nPg+JyWK+XbWSeCq mBG1Kb1xRxTOQ== Date: Fri, 13 Jun 2025 18:25:13 +0000 From: Pip Cet Message-ID: <87ikkzwlbu.fsf@protonmail.com> In-Reply-To: References: <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 90b6ace927e365221aadc65ed45fe735666da433 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Stefan Monnier" writes: >> What is a "normal quit"? > > A single C-g. > >> What is "emergency quit"? > > Something like `C-g C-g C-g`, tho we don't have that implemented, > currently, AFAIK. It's implemented. See handle_interrupt in keyboard.c: /* Request quit when it's safe. */ int count =3D NILP (Vquit_flag) ? 1 : force_quit_count + 1; force_quit_count =3D count; if (count =3D=3D 3) =09Vinhibit_quit =3D Qnil; Vquit_flag =3D Qt; The "emergency" part is clearing the inhibit-quit flag when force_quit_count reaches 3. The bug is that it should be >=3D 3, and the questionable design feature is that we should reset the counter if Vquit_flag and Vinhibit_quit are both nil, not just based on Vquit_flag. However, there's also the rest of handle_interrupt, which applies to terminal sessions and takes them through an interactive text adventure which never clears Vinhibit_quit. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 18:39:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174983992221946 (code B ref 78737); Fri, 13 Jun 2025 18:39:05 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 18:38:42 +0000 Received: from localhost ([127.0.0.1]:50532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ9IY-0005hu-1R for submit@debbugs.gnu.org; Fri, 13 Jun 2025 14:38:42 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:60072) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ9IW-0005hm-17 for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 14:38:40 -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=7kI4yfUTqomm1WeKx0Kn9HKY2hTm9ZrMq/VeY4Wu/L8=; b=N5ocImxlItqktwxiz8Fn73T0pl 7+rjv7aX2REGa8lJ4TFlwCIxKK/ZzvKcYcmpqUOveS7I88jfPsnwGka1fpyoCauWm6cp4kjxI+lHG GxdFCEnpwFKSkRyiOOsEc6DactEkp4D4VigVimqBcx4oEvluXc/Lj9g+EuaJAyz8COX9zMxRl2eRu YpYEFrMjK5BfRC0i4554KNevlmMiK5D4HgomIXwrT7Aq8dMgCd/rZ3TD6crTUNElq43qlFFdbbrpa G/fPh8HzOFveDdkAHm18yWj48MleDrHVJHhR/bRSkFk3a7UrLbyO/IUbWs8GdycxFrU1o7VmGKoa9 RLpcWfTw==; Received: from [164.86.16.50] (port=22818 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 1uQ9H6-00Bvku-0Y; Fri, 13 Jun 2025 14:37:12 -0400 Date: Fri, 13 Jun 2025 14:38:22 -0400 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <86frg3ttxc.fsf@gnu.org> References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <9EF7F59A-8131-4EB5-92B5-D7C805434C59@dancol.org> <86frg3ttxc.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-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 June 13, 2025 1:47:43 PM EDT, Eli Zaretskii wrote: >> Date: Fri, 13 Jun 2025 09:14:20 -0700 >> From: Daniel Colascione >> CC: pipcet@protonmail=2Ecom, 78737@debbugs=2Egnu=2Eorg >>=20 >> On June 13, 2025 9:03:21 AM PDT, Eli Zaretskii wrote: >> >> From: Stefan Monnier >> >> Cc: Daniel Colascione , 78737@debbugs=2Egnu=2E= org, Eli >> >> Zaretskii >> >> Date: Fri, 13 Jun 2025 10:51:37 -0400 >> >>=20 >> >> > Making >> >> > >> >> > (while t (read-event)) >> >> > >> >> > infloop without being able to quit is a bad idea=2E We shouldn't = do it=2E >> >>=20 >> >> I don't find this terribly problematic, If you think of what that lo= op >> >> means it *is* a "please shoot me in the foot" kind of thing=2E >> >>=20 >> >> I agree that not being able to escape is a problem, but it's not the >> >> only way to get into such trouble=2E IOW I think it just gets us ba= ck to >> >> the fact that we need an "emergency quit" for bugs (which `kill -USR= 2` >> >> can sometimes provide, tho it's not a quit per-se)=2E >> > >> >What I asked, and still didn't get an answer to, is at what point does >>=20 >> I believe I answered your question at length in and specifically ad= dressed the question above=2E I believe I'd addressed the subject several t= imes before as well=2E >>=20 >> Could you please take a look at the proposal before declaring these que= stions unanswered? > >I did=2E > >My current understanding is that what you propose will cause some >(most) programs to be interruptible with a single C-g, while some (in >particular those which call read-event) will need two or more C-g to >be interrupted=2E Is that correct? Yes=2E However, it looks right now like the class of program that has to be quit = with a repeated C-g is extremely small=2E I've seen only contrived examples= so far=2E Most programs do something with the result of calling read-even= t, and when they see C-g, either break out of their dispatch loop or do a C= -g appropriate thing=2E Things using low level input events like that, however, tend to be either = old or specialized=2E The most common code paths (e=2Eg=2E isearch, transient, map-y-or-n-p, etc= =2E) with dispatch loops already use higher level tools like read-key, read= -char-from-minibuffer, or transient keymaps and so get C-g handled as an in= put event anyway=2E Has anyone complained that (while t (read-key)) doesn't admit keyboard qui= tting? In practice, based on experience so far, there's no practical need to pres= s C-g any more often than one does on mainline=2E >If this is correct, then we need to decide whether this inconsistency >(one C-g vs several) is tolerable=2E I think it's correct only in theory=2E Maybe I'm wrong and there's some un= discovered case that this breaks=2E It's to discover these cases that it wo= uld be nice to test the branch and merge it to mainline=2E We can always pu= t it behind a feature flag=2E >> >Later responses by Daniel seem to indicate that the answer is "never"= =2E >> >It seems like his proposal is to change the behavior of C-g such that >> >to interrupt a Lisp program the user will need two or more C-g presses >> >(with the number customizable) during some predefine time interval=2E >> >Is that understanding correct? >>=20 >> No, that is not correct, and I've said so many times=2E I'm not sure wh= at I could say to increase clarity=2E > >Is the modified description above correct? If not, what is incorrect >in it? > >> Outside contrived corner cases, the only difference users will notice i= s that quitting works more reliably=2E > >Thanks, but that doesn't answer my question, which is specifically >about the effect of C-g on Lisp programs, whether they call read-event >or don't call it=2E Lisp programs that don't call read-event, read-char, or read-char-exclusiv= e don't see a change in behavior except for how, once we implement the repe= ated C-g work, users will be able to break out of loops like (while t (read= -key)) by pressing C-g multiple times=2E I have yet to see a real program that does something like this, much less = one that depends on bricking quit functionality in the user's Emacs session= =2E Lisp programs that do call these low level functions see a contract change= , as I detailed in my previous messages=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 18:46:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174984033024254 (code B ref 78737); Fri, 13 Jun 2025 18:46:05 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 18:45:30 +0000 Received: from localhost ([127.0.0.1]:50671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ9P5-0006Id-2D for submit@debbugs.gnu.org; Fri, 13 Jun 2025 14:45:29 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:59506) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ9P2-0006Hq-FZ for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 14:45:25 -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=7cSqZRxZD3ajKFxATswjjO4b2osY7fRFfgSSHKOI4Lg=; b=Hk0j6viRIWK/3qelfLg8KGtotS lP3xUx/HvNx3Lwn5Rt4vpYuewlphxV3WcAgCrRIvSKFNff+HdyHzaQ0H277p4EfnT7dXsD2u1sLMT f7bTCnwjKNvHamPjgBjDlVDW5W9TQRUajTasWYQKcFOwhMAgsVuYQ8WrUrn4yFboMotF0NpelMMoF Juqb/9rMrPKDlT3L8Cmym88bl8Xhm8GpDUBBJcAyfAXW1i2NJaoH0YEOdFa/Ljx8RGwyT7oaSPQf2 q1/eZf3FZDjOzdhqybbY+iO01owLwJ/bPA965A6LC/66WB4tFoRQZV0PGRxEI+cKSDeOsTGlRb5mb 8ykLlmEw==; Received: from [164.86.16.50] (port=41041 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 1uQ9Ne-00BvnG-1d; Fri, 13 Jun 2025 14:43:59 -0400 Date: Fri, 13 Jun 2025 14:43:54 -0400 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> <86y0twerm0.fsf@gnu.org> <86jz5ftuk8.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-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 June 13, 2025 2:14:44 PM EDT, Stefan Monnier wrote: >>> > (while t >>> > (let (evt (read-event)) >>> > (do-something-with evt))) >>> > >>> > _can_ be interrupted? >>>=20 >>> Usually the `(do-something-with evt)` part will offer some way to end >>> the loop=2E >> >> How? If read-event returns the character 7, then the information >> about the fact that C-g was typed is lost by the time we get to the >> do-something-with part, no? > >AFAIK that information is in `evt` and hence not lost=2E >Usually `do-something-with` will look at `evt` and do various things >depending on the key that was pressed and usually one of those options >lets you end what you were doing=2E > >Some code may assume they don't need to explicitly abort when `evt` is >7 because they rely on the current behavior of `read-event`, but AFAIK >that behavior is not completely reliable (e=2Eg=2E it depends on Yes=2E It's not reliable today=2E An example I gave earlier: on master, pu= tting C-g into unread-command-events makes the next read-event return 7, n= ot signal quit=2E >`inhibit-quit` and sometimes timing), so if we want to encourage use of >that feature we should try and make it more reliable=2E We should steer developers away from read-char and towards higher level fe= atures like read-key anyway, right? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 18:46:09 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet , Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174984035024295 (code B ref 78737); Fri, 13 Jun 2025 18:46:09 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 18:45:50 +0000 Received: from localhost ([127.0.0.1]:50686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ9PS-0006Jm-DL for submit@debbugs.gnu.org; Fri, 13 Jun 2025 14:45:50 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:56428) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ9PP-0006Jd-MK for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 14:45:48 -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=wLtSb1yuIBCKEAAWJ4x1ImsUzYViTgNtlV77FZkNmM0=; b=SP1BAKQkzpQbqjCwbpcvkLUust SJ7KwwCRq0B5KJhzQM1qN0SBxae5K4G3kGD3uxv6IcbbMfUv9h7Lr+HD0JYU2/e8G01OeljBWkLet 28Ep5q6vy5IBtg0hRaAlI/CQNPX875CSHQsfKq0BHCzUp6E3HsDh5oT8rO2XMV/mOdl/voDR6jPRO p6WuxTck1keYsMxWNmvkqhkAdqxEvueOrIxv1PIEsXoa5j5yhKa4bW5aWelE9JObN3XT/EEBieaYY leHhEQBNOVJLL8uOHw8w1/5Q1R1coRw2GJgBfUDvyF6l1aMC3+sRK8D7gL5Vxs4H1XDbwxHRsJarP gfHZDCcA==; Received: from [164.86.16.50] (port=63011 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 1uQ9O1-00BvnQ-1P; Fri, 13 Jun 2025 14:44:22 -0400 Date: Fri, 13 Jun 2025 14:45:26 -0400 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <87ikkzwlbu.fsf@protonmail.com> References: <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> <87ikkzwlbu.fsf@protonmail.com> Message-ID: <40E6566B-8F12-4D2B-807F-74EC75BFBEEB@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 13, 2025 2:25:13 PM EDT, Pip Cet wrote: >"Stefan Monnier" writes: > >>> What is a "normal quit"? >> >> A single C-g=2E >> >>> What is "emergency quit"? >> >> Something like `C-g C-g C-g`, tho we don't have that implemented, >> currently, AFAIK=2E > >It's implemented=2E See handle_interrupt in keyboard=2Ec: > > /* Request quit when it's safe=2E */ > int count =3D NILP (Vquit_flag) ? 1 : force_quit_count + 1; > force_quit_count =3D count; > if (count =3D=3D 3) > Vinhibit_quit =3D Qnil; > Vquit_flag =3D Qt; > >The "emergency" part is clearing the inhibit-quit flag when >force_quit_count reaches 3=2E The bug is that it should be >=3D 3, and t= he >questionable design feature is that we should reset the counter if >Vquit_flag and Vinhibit_quit are both nil, not just based on Vquit_flag= =2E > >However, there's also the rest of handle_interrupt, which applies to >terminal sessions and takes them through an interactive text adventure >which never clears Vinhibit_quit=2E Yes=2E We need something like the force quit code you posted in spirit, bu= t I don't think that's the right implementation because it's too easy to pr= ematurely clear the quit flag=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 18:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174984068626004 (code B ref 78737); Fri, 13 Jun 2025 18:52:01 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 18:51:26 +0000 Received: from localhost ([127.0.0.1]:50810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ9Ur-0006lK-O9 for submit@debbugs.gnu.org; Fri, 13 Jun 2025 14:51:26 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:46544) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ9Up-0006l9-Ei for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 14:51:24 -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=z03qER16RUA244vHDEOInSEQKLSrtinu7081vWrMfV4=; b=mps/xaFceKCUoc8frHIl7ob6cw S3QcAbr9zAlbH9KgCZaUXl2o7DA2p0qrxMn3wsV5eizAGHvHkJ+d8WDKSHREk+GNVgnIuB6LUmpQN V5xQHkbjIEcMO5tWPEWdex90hTau7Jbn0BSNBQOzs/yX9T+yXfJSxACDGR+kgxwSeTUOyvsrxxitR Og91IbjsrTAupEtjSCFppSdIqGpc5r6M017qayTFRPIL476nZwbmqm4jmgN8eAu/xfJoRPgtHtr/x 4DZIEfJp8wx8XIHgee1NfgDCkNYGg4jE/DbFP7hC3Xjnj+4FFxTM6eww5NmniXXO577WN3W8nJrO6 hGHUGCUg==; Received: from [164.86.16.50] (port=42595 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 1uQ9TQ-00Bvo9-1t; Fri, 13 Jun 2025 14:49:57 -0400 Date: Fri, 13 Jun 2025 14:51:08 -0400 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.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-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 June 13, 2025 2:00:31 PM EDT, Stefan Monnier wrote: >>>> What I asked, and still didn't get an answer to, is at what point doe= s >>>> a program that calls read-event becomes interruptible by a single C-g= , >>>> after the changes on the branch? >>>It's interrupted if the `C-g` occurs while running the code rather than >>>while sitting inside `read-event`=2E For the tight `while t` loop, it'= s >>>virtually never=2E >> For clarity's sake, Stefan is describing what's in the branch right now= and >> I'm describing what will be on the branch before it's ready for merging= =2E > >I thought the difference was only in terms of "emergency quit", which >I think is not what Eli referred to when he meant "interruptible"=2E To be clear, when I say that a Lisp form is interruptible, I mean that it = is *possible* to break out of it using enough C-g presses=2E For example, = this code, which is not interruptible at all in current master, (while t (read-key)) becomes interruptible, the way I'm defining it, when you press C-g >=3D N = times=2E This code is interruptible on both master and in my proposal: (while t (read-event)) However, on master, you need only one C-g to interrupt it=2E In the idea w= e're discussing, you need N (so 2 or 3 or whatever we set N to)=2E That might seem like a disadvantage of a UI change, but it isn't really be= cause loops like the above don't occur in practice=2E >[ I suspect these kinds of differences of intended meaning are >a significant part of the misunderstandings in this thread=2E ] Yes=2E I think there's quite a bit of talking past each other=2E > > > Stefan > From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 19:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier , Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174984168430963 (code B ref 78737); Fri, 13 Jun 2025 19:09:02 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 19:08:04 +0000 Received: from localhost ([127.0.0.1]:51218 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQ9kx-00083L-V4 for submit@debbugs.gnu.org; Fri, 13 Jun 2025 15:08:04 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:59122) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQ9ku-00082v-VC for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 15:08:02 -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=WouiKm8IKnWM5E3rw/cLH/NcnvB9N0iUBBytYSOgU7I=; b=a5EYmJCilyDEK/RPTHf4FSuEml RHsmDqBgFxKD7XdXqex1AF3n8monR7s4VcYYB13nadLAVM7T6muhE3Qfg9E+/8NDf4uke+/uOlJnt fycraq127ZHqs6wH/p098OhHhAGYTeyYy9ZQtnzS0Ot7zGj2kutcpxYgo7CbJON+SslasHHrrOc67 02yoiKc8EtIvIEbLLYM60nvN6elkqUhnDSj15e3k99dTTzlbtbna8tzd40PioYsmoe3Cfe01R8Ss8 tismokBUgS9iIjSt9eI2evv4yyq8xSakF1/j02H0Uahy+Fmm3rZoGaCWmFNgd9ouXaKnphCmk3lL4 nP8aM+pA==; Received: from [164.86.16.50] (port=22354 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 1uQ9jV-00Bvqr-1V; Fri, 13 Jun 2025 15:06:34 -0400 Date: Fri, 13 Jun 2025 15:07:51 -0400 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> Message-ID: <4BCDF146-4265-4070-9223-E6A6902F6BC9@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 13, 2025 2:16:08 PM EDT, Stefan Monnier wrote: >> What is a "normal quit"? > >A single C-g=2E > >> What is "emergency quit"? > >Something like `C-g C-g C-g`, tho we don't have that implemented, >currently, AFAIK=2E How about this terminology? C-g --- normal quit C-g C-g C-g --- urgent quit (breaks out of read-event=2E should probably b= reak out of redisplay too?) C-g C-g C-g C-g C-g C-g --- emergency quit=2E ignores inhibit-quit=2E good= chance of horking your Emacs by violating atomicity assumptions=2E Display= "are you sure?" message before final C-g=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Lynn Winebarger Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Jun 2025 21:57:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Pip Cet , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174985177717947 (code B ref 78737); Fri, 13 Jun 2025 21:57:04 +0000 Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 21:56:17 +0000 Received: from localhost ([127.0.0.1]:53102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQCNi-0004ew-BF for submit@debbugs.gnu.org; Fri, 13 Jun 2025 17:56:16 -0400 Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:39183) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQCNb-0004cf-LV for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 17:56:11 -0400 Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-3a528e301b0so289935f8f.1 for <78737@debbugs.gnu.org>; Fri, 13 Jun 2025 14:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749851761; x=1750456561; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=C7ZSuDw2guLHRGoVMoSPTIoO3pKtv/2wtE3I6J9H6Rc=; b=BYJazlDAIPOs0sLC5NnR/b6E3sPbDAdgXsCg9SisANVyWfBSi1KfX1VUhb5/61mEOp oTpNPZBMoT0ShIayskmuzH5ocaCYL8vOomHEIa19g7f2laFVZcaGYCfeNKnb+iKfS9qj fE94FfGfQAVYk5aFVZGSSWYqXunxNL9ciYAeNZD8IldL6K/awgM8BhHp8BoOfHO7nyHF +/LeGTX6qvKgosljjKEw3fVe3mPp5uKdknp78LnnW66IXvRrg+u2ZuI3NY6YxTS8q4Ta Zggwfm1pQ2NSXY5W1qYxgjjnGCXC0lUYDvvI3ONReoREQtaEaj7nJZw/BzAZ1nkZEdXi oHTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749851761; x=1750456561; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=C7ZSuDw2guLHRGoVMoSPTIoO3pKtv/2wtE3I6J9H6Rc=; b=SUPblMgb/obnZKT6u9jroMgnWhS6/7DFOBO3O3eFKvZzxFMaAlBRwk8b9tWJyxSaTH FhsxFlChIqoRNoKenKE36n5ZTzDnKKAwcgQvNPiQ/q7WxKbMb6j4flZE4W9A7px52pQc BqdS6Tsy3hCOkd+YGBbZQ1uGrSEZYXOfxPWhrTjdk/6qsdEtX20oiFpBY0CsdsyRM0DG ROzEQSThjelo/McRrT/PjP5lVUdJsfrf8lMyEMrK2SD5RH8fuhqwuT9AH1tvg0x0xGVG 4rsUkonfZ1n4PbCC9rNqjMmr9mWClgzFWZA7rIwFKjVvn9Rg3ylaTQJLC0h5niq/JRzQ ZeXA== X-Forwarded-Encrypted: i=1; AJvYcCXURMqIfuOF5Qw6QGIWkGKJ2JVDicpVYLDS+Op0RoRZSQXm4TjeRtpjjfogjhH32VDdl9458g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzcjLisASk4EpB+DUKJWkIdc8qw+CFL6gIM3JgvrmqEa9wRhwVB jVX4Prhk9yuzZF91Zxr4AfCUD51t3ksYUP+j9hjOyEgA+45dO/INzLcAYUnEW7lWgl8Xc3/uKD3 ydu4XRCHEeHhqBYEbXMBWi6uS63IvmEY= X-Gm-Gg: ASbGnctMqUJfNH0FrnwqnLilv2agv4nZbWLebQmYi4w2ux1chKBqXTMKmq+H89mMh3E ta6/KoN+eG7ya5MNjxezr8CF8zlNLYMofWRklTqOhix00g9VHq7Dk+aOujtWXvsXEbSl0R1MDJV sG2v7y/FKPtBSSIZ2uT8zni05ZeXk9M+Emv1pqWK73T6TymXHxtaD9N7nm X-Google-Smtp-Source: AGHT+IHkhdvWZL+Hhy/t69qOPmTc7m0JMz7KnN3U/rGFlUwpb0rqJrOoKc1eJQR72290pC7wtmpvz0oWlU6/OAlaKT8= X-Received: by 2002:a05:6000:25c7:b0:3a4:da29:d13f with SMTP id ffacd0b85a97d-3a572366113mr431120f8f.3.1749851760883; Fri, 13 Jun 2025 14:56:00 -0700 (PDT) MIME-Version: 1.0 References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> <37BCCFA8-8EFC-4BB1-8B4F-D805FB7E1B6A@dancol.org> In-Reply-To: <37BCCFA8-8EFC-4BB1-8B4F-D805FB7E1B6A@dancol.org> From: Lynn Winebarger Date: Fri, 13 Jun 2025 17:55:49 -0400 X-Gm-Features: AX0GCFs5kOx30ywg16fVGeo3EcSQo8toHHXKQVrJEaJAuDjgMVQ-qypHNJuBtGU Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 Fri, Jun 13, 2025 at 10:02=E2=80=AFAM Daniel Colascione wrote: > > > > On June 13, 2025 6:42:58 AM PDT, Daniel Colascione wr= ote: > > > > > >On June 13, 2025 5:23:34 AM PDT, Lynn Winebarger wr= ote: > >>On Fri, Jun 13, 2025, 2:26=E2=80=AFAM Eli Zaretskii wrot= e: > >> > >>> > From: Daniel Colascione > >>> > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, > >>> > 78737@debbugs.gnu.org > >>> > Date: Thu, 12 Jun 2025 11:48:50 -0700 > >>> > > >>> > Pip Cet writes: > >>> > > >>> > > I'd like read-event, when called while inhibit-quit is t, to repo= rt > >>> > > quits by setting quit-flag in addition to returning quit_char: it= 'll > >>> > > simplify the C code, and it would make > >>> > > > >>> > > (while t > >>> > > (let ((inhibit-quit t)) > >>> > > (read-event))) > >>> > > >>> > I strongly disagree. read-event should read an event. > >>> > Setting quit-flag by side effect when it happens to read one key an= d not > >>> > others makes the interface less regular and understandable. > >>> > >>> We should start by agreeing that the capability of interrupting a > >>> running Lisp program is a real need. Are we in agreement about that? > >>> If not, let's first hear the arguments why not. > >>> > >>> If we _are_ in agreement about that, we should discuss how this shoul= d > >>> be possible if read-event (and perhaps others?) return C-g instead of > >>> raising quit-flag. The alternatives mentioned until now are: > >>> > >>> . restore the old behavior, whereby C-g interrupts read-event > >>> . have a variable that, if set, will restore the old behavior in > >>> read-event and other affected primitives, to be interruptible by a > >>> single C-g > >>> . make two C-g presses "in quick succession" set quit-flag, IOW > >>> "C-g C-g" will have the same effect as C-g previously > >>> > >>> Are there other alternatives? > >>> > >> > >>What about keeping a (possibly buffer-local?) lisp variable holding a l= ist > >>of keystrokes mapped to thunks that are treated as generating lisp mach= ine > >>"interrupts"? The key strokes would be processed by C machinery and ne= ver > >>seen directly by lisp code and not be considered "events". > >>Then C-g could be bound to a thunk signalling quit, and the effect of > >>"inhibit-quit" achieved by removing C-g from the list in a given dynami= c > >>scope. Then user code could make other key-strokes "special" without > >>resorting to read-event. For example, this read-event call in term.el: > >>(message "Hit space to flush") > >> (let ((ch (read-event))) > >> (if (eq ch ?\s) > >> (set-window-configuration conf) > >> (push ch unread-command-events))) > >> > >>Could be replaced by something like > >>(with-interrupts ((?\s (signal term-flush))) > >> (condition-case nil > >> (while t (sit-for 100)) > >> (term-flush (set-window-configuration conf)))) > >> > >>Then some of these use-case concerns could be mooted altogether. > > > >We already have something like that. :-) read-event already runs the eve= nts it reads through special-event-map, right? We don't even need to create= a separate thunk list concept: we could just bind C-g in special event map= and do what we want, right? Would that provide the behavior Pip is looking for? I can't pretend to understand what is going on in read_char, but it looks like that map isn't applied to *every* key entered, to ensure they are removed from the normal event stream. > >The only special thing about C-g is how we treat it when Lisp is running= . When it's instead reading an event, it can and be a boring event processe= d the same way every other event is. It seems to me what Pip is looking for is analogous to a "Quit" button hardwired to a pin on a CPU, which is not something that can be reliably implemented in the C primitives as they are now. That would mean adding "interrupts" to the lisp machine architecture. If I think about it seriously, I guess I would be talking about a mechanism incorporated into signal handlers that would do surgery on the appropriate thread's C/Lisp machine stack so that when that machine's operation is resumed, the active frame would be for a call to the registered interrupt handler, arranged to return to cleanly return to wherever the C code was before the signal, unless the interrupt handler performed a non-local exit, like (signal 'quit). Maybe the interrupt handler shouldn't be a thunk, but take two arguments: the data delivered with the signal (in this case the keystroke) and a timestamp, so your " quits in milliseconds" could be implemented when there are multiple keystrokes before the lisp thread resumes. In this scenario, the signal handler would never deliver "hard-wired" interrupt keystrokes to the event queue processed by read_char. It would also mean a C-g (or other designated interrupt) could be processed earlier than preceding keystrokes, but that seems like what Pip would want? Theoretically, such interrupt handlers could be required to be byte-code functions that don't use any operations that could produce unbounded stack usage, most notably no call instructions, or certified by the native compiler to be "safe" for use with interrupts. Also, byte-code ops for "signal" and "throw" would need to be added. The possibility of forcing a non-local exit on the lisp thread would be the whole point of arranging a handler to run on that thread in the first place. Anyway, this kind of restriction would probably scare-off any non-serious uses of the facility. This approach is really too low-level for the use I suggested in term.el, though I do think there should be some way of saying "wake me up when this key is pressed" and either block until that happens (queueing other keystrokes) or let the command loop do whatever it normally would if that makes sense. > Oh yeah, one thing I forgot to mention: for the *asynchronous* case, the = C code is pretty deeply coupled to quit_char, and IIRC, even hard codes 7, = C-g, in some places instead of quit_char. In your proposal, we'd references= to quit_char and literal 7 to calls to a new bool is_quit_char(int c) func= tion -- and this function would return true for any raw keys bound in speci= al-event-map. In this way, you'd be able to define as many asynchronous-inp= ut characters as you wanted. I guess I would consider removing that kind of hard-coded logic a plus? > > We wouldn't get the special SIGINT behavior this way (because in termios = there can be only one interrupt key, right?), but I think that's okay, sinc= e quitting works without the SIGINT wiring and I suspect that we could remo= ve the SIGINT wiring and simplify the codebase without losing any actual fu= nctionality. I suppose I am thinking from the perspective of making the lisp machine more machine-like, to facilitate the possibility of running multiple elisp "cpus" or "cores" in the same process, but that's all pie in the sky at this point. I'd like to see inputs and displays become clean sources and sinks, with the threads processing the data freed from concerns like whether redisplay will be called. Like having dedicated coprocessors for I/O devices, with the lisp machine core primitives just concerned with the data structures (like buffers) they manage. I'm talking awfully big for someone struggling to make read0/readevalloop re-entrant enough to interleave progressive evaluation of forms in a string with loading a file or evaluating a buffer. Lynn From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 03:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione , Pip Cet , Lynn Winebarger Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174987263512210 (code B ref 78737); Sat, 14 Jun 2025 03:44:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 03:43:55 +0000 Received: from localhost ([127.0.0.1]:57963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQHo9-0003Aa-7G for submit@debbugs.gnu.org; Fri, 13 Jun 2025 23:43:55 -0400 Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:47275) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQHo5-00039J-Ur for 78737@debbugs.gnu.org; Fri, 13 Jun 2025 23:43:51 -0400 Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-60780d74c85so4179740a12.2 for <78737@debbugs.gnu.org>; Fri, 13 Jun 2025 20:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749872624; x=1750477424; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=HailPhn3EDX6581y4DUXWuJHbQMqwEWWoLPyEwsT4gM=; b=GaJ2SKG6Gkos/JzH5Im2pPGu+FXiXJjJpGKko4eIyBEh+x85prOWE+eAc2erpm/Yv7 M/zQhUAzNMy0+kRJUE0wqK0T2KTZazMXIIQO//4EATqlaAcYG6VxE9PSx6VLlMBQLYdN iH8xfvGC+rErhq5M3V0pMqF/h2b7lEtsg8cI23zIQj7hBn9XIuIPNxdjkmM/hx7Ep0Y3 4/hNTi877MBWXN90F2cP1my+r5XsQN5vAGp43RXIAxkITEcGDPQcFl4wPdk4chSuIw0y uw0eduMqWPyai4udVC0bLMfT88VmCOYaRL3YMA5wyRICZuqfHiX82RriUweCHRIARU3a sDoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749872624; x=1750477424; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=HailPhn3EDX6581y4DUXWuJHbQMqwEWWoLPyEwsT4gM=; b=w/t9hGaM24NS2MBSzMw6BsULlbC/67vkHzBPT1McLMudEY593DmSTc+PkHqtgZptCa WM0Y2HMCmxsHOvMPpaRIlkcRbrs2mW/iMx3w7NvzK4uMy4yRhGPHHK2KjufKATLIlprd E+gxdqabIW2ozdP1I/HrXDx2KTTcO7GINKPPAEF4UuXGD5qEghPbF+NR7rtreAFHu3lH m9Gs7uj8ZEvwuqNMT816blNLTxsVZh+k+9anNSD1XMJZ+QcU1TrMLtIjZmr5CXGYDIZo sdcjeLCKla7j2pvNfFlQiXdJq+ZVPQjcOGVQIcQVLz7pUyZ+UGRtCMCIY8oz1aWncrHG PFaA== X-Forwarded-Encrypted: i=1; AJvYcCW7hm/IpDlw6xaFxLjImNjIjeRzVAXfiLOvzQVa3NISLZX3dGSZlKZcmB9GBRo3DQ37/Fmg7w==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxJW8opUUeC9qoxfJK62ttVCxkmGZOdiECn/dLWCe3XgS+i2QAV AB+WFMH7iNl0urKCn9fT6Pj7DPiGGrXbJdF1fCTPFZyTehFBEEnW7ES9 X-Gm-Gg: ASbGncsDnTLVIHf873gm0j3sbi54QvQQOoVFrYnccsiWsuDtG5hAp5UpDzJFCWLWWz6 7JWld54MhoCKosA87A5RPSj+1GFBH+TIhC03MKpvhZyw1bArru2e9Gmrcat7UNV+q/V4TrjNi2j kSIVudYxoOEokGmPpMFSxuTnTiZPWJ8sICKJiDWNTpJflPTpj0+NzdvrQbZM/3dH6AwySiwz67h /QlWX4jJPVT/NnBxFequeWdtvmCHN1wZFKO2IQa5KoxAlMyefm9LgZ/8w+DE2Crxtjh3yO4yGdj 71kMK+usm8/rBWYSUErdc751qbT4Nijr3LIA8snzeaqisRiSQKEVBcqzxCtoqorKekyewUxi4G9 SQwr3DYQg3dtUYPJpMRcT2QPrz61O+zYWzh/VNSIXpkoQnfFwaOd24gYKlo6x0sFhcGdhrw== X-Google-Smtp-Source: AGHT+IEhOpYjZ1gkzmXkXKskd3eU1NTMA71WeMKzd/QqUfwQ4I6uDSAyBUDChmdORlgoUcwjnDp+3A== X-Received: by 2002:a17:906:6a0a:b0:ad5:372d:87e3 with SMTP id a640c23a62f3a-adfad36811fmr137225266b.27.1749872623450; Fri, 13 Jun 2025 20:43:43 -0700 (PDT) Received: from pro2 (p200300e0b70f7d0009aae6d1cf8a57cf.dip0.t-ipconnect.de. [2003:e0:b70f:7d00:9aa:e6d1:cf8a:57cf]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-adec8982f4esm232165466b.176.2025.06.13.20.43.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Jun 2025 20:43:42 -0700 (PDT) From: Gerd =?UTF-8?Q?M=C3=B6llmann?= In-Reply-To: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> Date: Sat, 14 Jun 2025 05:43:41 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) Stefan Monnier writes: >>> We already have something like that. :-) read-event already runs the >>> events it reads through special-event-map, right? >> Entirely unrelated, I just came across this because I searched for >> read-event. Let me just mention that read-event does not respect >> input-decode-map. This is a problem on ttys, see bug#75886. > > Currently the only "decoding" we have to turn the TTY input bytes into > events is limited to the keyboard-coding-system thingy. =F0=9F=99=81 > > Maybe I should have implemented `input-decode-map` directly inside > `read-event`, but I think it goes contrary to the design. > > It's usually better to change the users to use a higher-level function > instead, such as `read-key`. > > Admittedly, if you want to recognize a quit event encoded as an escape > sequence, that's not going to help you because we need/want those events > to be decoded at as-low a level as we can. =F0=9F=99=81 I'd deprecate read-event TBH. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 06:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498823438853 (code B ref 78737); Sat, 14 Jun 2025 06:26:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 06:25:43 +0000 Received: from localhost ([127.0.0.1]:59293 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQKKk-0002Ib-As for submit@debbugs.gnu.org; Sat, 14 Jun 2025 02:25:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51268) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQKKh-0002IM-WB for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 02:25:40 -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 1uQKKb-0001CU-2q; Sat, 14 Jun 2025 02:25:33 -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=R7KOQ6CV2yRzJLgzjRhbj0Fwi3lt6vW5jd/nIXmSc3s=; b=LwXOgXjEzcRV lYW6LcenCUbMQmWBC5KJMlYnr+K/WLuq5YRDS5T6rQlAjfZMXfFno4W+HljNnQi3aFt5Sh4HHdT+C 2bnqSvW85rewVn2xOHNe8sAD7LnB4E4PFckaIpMnuU9R6cGXBVYp/lKhp2aV0VTT7xtk9tdC/DdC9 n6e74/rpgXxwQcRvCn68jdSd36SSAMlCVjFo89vZnLG08bT59EqNqylAmgPp03zmT4EJfxK7+qCg5 T/HD69V54MC4kslVXpeFicQj+2vyFgvHKohcPjgnYedkFKbrfZBY+h+qk7ail7knYTX+Db1UbjAd9 8KgaKWvU9C2Z3qdEbbEihg==; Date: Sat, 14 Jun 2025 09:25:28 +0300 Message-Id: <868qluu9ev.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Fri, 13 Jun 2025 14:00:31 -0400) References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Stefan Monnier > Cc: Eli Zaretskii , pipcet@protonmail.com, > 78737@debbugs.gnu.org > Date: Fri, 13 Jun 2025 14:00:31 -0400 > > >>> What I asked, and still didn't get an answer to, is at what point does > >>> a program that calls read-event becomes interruptible by a single C-g, > >>> after the changes on the branch? > >>It's interrupted if the `C-g` occurs while running the code rather than > >>while sitting inside `read-event`. For the tight `while t` loop, it's > >>virtually never. > > For clarity's sake, Stefan is describing what's in the branch right now and > > I'm describing what will be on the branch before it's ready for merging. > > I thought the difference was only in terms of "emergency quit", which > I think is not what Eli referred to when he meant "interruptible". No, this is a gross misunderstanding of what I was saying, and IMO of the whole discussion. By "interruptible" I mean the ability of interrupt a Lisp program with a single C-g. Currently, some Lisp programs cannot be interrupted that way (or in any way, except by SIGUSR2 or something similar), but most are. Changes proposed by Daniel make this small subset of programs a bit larger (AFAIU), so we are discussing whether that is a problem, how significant is that problem, and how to remedy it. "Emergency exit" (not "emergency quit", which never existed in Emacs) is the feature whereby typing more than 1 C-g would pop the question whether to exit Emacs and if so, whether to dump core. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 06:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lynn Winebarger Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498825059685 (code B ref 78737); Sat, 14 Jun 2025 06:29:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 06:28:25 +0000 Received: from localhost ([127.0.0.1]:59362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQKNM-0002W7-Cd for submit@debbugs.gnu.org; Sat, 14 Jun 2025 02:28:25 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:15703) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQKNH-0002Ur-4F for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 02:28:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749882492; x=1750141692; bh=9IuYfXM6/nkRGvw7mrOfrVaaC+VMBhjRuG4gqf4TXL8=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=ikZQEL0RoHjlh/6z+Yj4QsmR60JZextbpMl5PddD8mBNDqbM4YUdfYhVGUsLflkdS JVDzrn56gbXTKOGLbmAVp4Zp3xD67QvJsYZ15RkmOugS02V2MqfqBJPnH1YUMmdUT4 UIYeCjFwbIo717zZx6OOxRFKPcsxUOIDAmyJAzp8xyey/4Gc3cv0UFEAUVWN8yPu+4 O/MYGW8O8ZS43feZ2bEkNsuej/OHmSCdYkYQ+4ur+v2tQ15ok86vZoTWTfGPb0vSPR nuQObwfSI/zf7yr61/HcorzIpgPhxYtmk2mb/QusPfCz516t3e3qPbKcD3x0bjoY0m nR1Xref0Km2yw== Date: Sat, 14 Jun 2025 06:28:06 +0000 From: Pip Cet Message-ID: <874iwix2fk.fsf@protonmail.com> In-Reply-To: References: <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> <37BCCFA8-8EFC-4BB1-8B4F-D805FB7E1B6A@dancol.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0a4b519f50b6d9b64246848b3cdff617f056adf0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Lynn Winebarger" writes: > On Fri, Jun 13, 2025 at 10:02=E2=80=AFAM Daniel Colascione wrote: >> >> >> >> On June 13, 2025 6:42:58 AM PDT, Daniel Colascione w= rote: >> > >> > >> >On June 13, 2025 5:23:34 AM PDT, Lynn Winebarger w= rote: >> >>On Fri, Jun 13, 2025, 2:26=E2=80=AFAM Eli Zaretskii wro= te: >> >> >> >>> > From: Daniel Colascione >> >>> > Cc: Eli Zaretskii , monnier@iro.umontreal.ca, >> >>> > 78737@debbugs.gnu.org >> >>> > Date: Thu, 12 Jun 2025 11:48:50 -0700 >> >>> > >> >>> > Pip Cet writes: >> >>> > >> >>> > > I'd like read-event, when called while inhibit-quit is t, to rep= ort >> >>> > > quits by setting quit-flag in addition to returning quit_char: i= t'll >> >>> > > simplify the C code, and it would make >> >>> > > >> >>> > > (while t >> >>> > > (let ((inhibit-quit t)) >> >>> > > (read-event))) >> >>> > >> >>> > I strongly disagree. read-event should read an event. >> >>> > Setting quit-flag by side effect when it happens to read one key a= nd not >> >>> > others makes the interface less regular and understandable. >> >>> >> >>> We should start by agreeing that the capability of interrupting a >> >>> running Lisp program is a real need. Are we in agreement about that= ? >> >>> If not, let's first hear the arguments why not. >> >>> >> >>> If we _are_ in agreement about that, we should discuss how this shou= ld >> >>> be possible if read-event (and perhaps others?) return C-g instead o= f >> >>> raising quit-flag. The alternatives mentioned until now are: >> >>> >> >>> . restore the old behavior, whereby C-g interrupts read-event >> >>> . have a variable that, if set, will restore the old behavior in >> >>> read-event and other affected primitives, to be interruptible by = a >> >>> single C-g >> >>> . make two C-g presses "in quick succession" set quit-flag, IOW >> >>> "C-g C-g" will have the same effect as C-g previously >> >>> >> >>> Are there other alternatives? >> >>> >> >> >> >>What about keeping a (possibly buffer-local?) lisp variable holding a = list >> >>of keystrokes mapped to thunks that are treated as generating lisp mac= hine >> >>"interrupts"? The key strokes would be processed by C machinery and n= ever >> >>seen directly by lisp code and not be considered "events". >> >>Then C-g could be bound to a thunk signalling quit, and the effect of >> >>"inhibit-quit" achieved by removing C-g from the list in a given dynam= ic >> >>scope. Then user code could make other key-strokes "special" without >> >>resorting to read-event. For example, this read-event call in term.el= : >> >>(message "Hit space to flush") >> >> (let ((ch (read-event))) >> >> (if (eq ch ?\s) >> >> (set-window-configuration conf) >> >> (push ch unread-command-events))) >> >> >> >>Could be replaced by something like >> >>(with-interrupts ((?\s (signal term-flush))) >> >> (condition-case nil >> >> (while t (sit-for 100)) >> >> (term-flush (set-window-configuration conf)))) >> >> >> >>Then some of these use-case concerns could be mooted altogether. >> > >> >We already have something like that. :-) read-event already runs >> > the events it reads through special-event-map, right? We don't >> > even need to create a separate thunk list concept: we could just >> > bind C-g in special event map and do what we want, right? > Would that provide the behavior Pip is looking for? It would not, because quits are currently processed out-of-order, and this important feature should remain in place for "serious" quits. See below. >> >The only special thing about C-g is how we treat it when Lisp is >> > running. When it's instead reading an event, it can and be a >> > boring event processed the same way every other event is. > It seems to me what Pip is looking for is analogous to a "Quit" button > hardwired to a pin on a CPU, which is not something that can be > reliably implemented in the C primitives as they are now. You're suggesting I'm looking for something that cannot be implemented. I'm not. I described specific situations in which I think quit should be expanded to work better than it does now. No one's expecting that quit works in absolutely every situation, as far as I know. That's what gdb is for. If you're referring to the "C-g C-g" thing, I did not describe how I'd implement it in detail, because there are many choices to be made; but the main idea would be that we should not immediately clear inhibit-quit for that combination, because that's a dangerous and destructive thing to do. If we decide to do so (after a delay, for example), we need to print a clear warning to the user that their Emacs session needs restarting. So C-g C-g might do less than GUI C-g C-g C-g does currently. There are actions even more dangerous than clearing inhibit-quit. I don't know whether we want a level-3 quit which does even more than the current GUI C-g C-g C-g code. But, again, such decisions ultimately require actually writing code, and I haven't, so far. > It would also mean a C-g (or other designated interrupt) could be > processed earlier than preceding keystrokes, but that seems like what > Pip would want? That's the current behavior. I'd like to keep it. Quit has some immediate effects, including sometimes clearing unread-command-events, discarding queued input. It also sets the quit flag before other input is processed. It then causes an actual quit, which is an error, which causes Fdiscard_input to be called. >> Oh yeah, one thing I forgot to mention: for the *asynchronous* case, >> the C code is pretty deeply coupled to quit_char, and IIRC, even >> hard codes 7, C-g, in some places instead of quit_char. In your >> proposal, we'd references to quit_char and literal 7 to calls to a >> new bool is_quit_char(int c) function -- and this function would >> return true for any raw keys bound in special-event-map. In this >> way, you'd be able to define as many asynchronous-input characters >> as you wanted. > I guess I would consider removing that kind of hard-coded logic a > plus? I think whether to make quit_char configurable (in GUI sessions) or keep the code which makes it configurable (in terminal sessions only) is a very minor detail. This comment in bindings.el: ;; The following wouldn't work to interrupt running code since C-g is ;; treated specially in the event loop. ;; (define-key global-map [stop]=09=09'keyboard-quit) ; Sun suggests someone once wanted to add an additional quit_char and gave up. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 06:47:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, dancol@dancol.org, Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174988357814331 (code B ref 78737); Sat, 14 Jun 2025 06:47:03 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 06:46:18 +0000 Received: from localhost ([127.0.0.1]:59598 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQKeg-0003j4-0e for submit@debbugs.gnu.org; Sat, 14 Jun 2025 02:46:18 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:35167) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQKee-0003ir-Ke for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 02:46:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749883569; x=1750142769; bh=qzmoFbW5vUVlNuQu4ClD445TFU+By2cQV0Gdx6qNibc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=TiUQcz5HbSjr617xkQAA1dcxX2iuwFG9P46XrJ/JuGkLF1SplIG0Qx/WRXm/qYiNN fovNPpwbLuD+Gdb50QeIgd579blZ/DKxqDq0hAAGVyjwA7Ad76zzMXP9UUv2kGLrTg zyMxNRDZC40MNcrUpDjX/+4x0kj00u1RauIg90MdYYIq89kHtlO+ps1/yIdQi9eCqk eIvjsgrwGLD0/CMllBOizCgbBdTP5O9X52IxN73o/eNXudTPOkjLvgsU5PRirRR+S5 zCF64RfSvPpTp/iY73F24FhBz9g1VVlXgVIPYkPB5Da63boryFppzAShJ3uXnxLajV 4uZimKUxBqn5w== Date: Sat, 14 Jun 2025 06:46:03 +0000 From: Pip Cet Message-ID: <87y0tuvn15.fsf@protonmail.com> In-Reply-To: <868qluu9ev.fsf@gnu.org> References: <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <868qluu9ev.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b7ef82c6d1356e541ffc86bc487450403166fdea MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Eli Zaretskii" writes: > "Emergency exit" (not "emergency quit", which never existed in Emacs) > is the feature whereby typing more than 1 C-g would pop the question > whether to exit Emacs and if so, whether to dump core. Sorry if I'm being dense, but just to recap: "Emergency exit" works in sessions that have a terminal frame. In such sessions, the code manipulating force_quit_count is never reached. In GUI sessions, this code is reached, and hitting C-g three times while quit-flag is set will perform a special kind of quit, clearing inhibit-quit. IIUC, you object to calling this special kind of quit "emergency quit", and would prefer to call it something else. Is that right? What's the preferred term for this special kind of quit? I'm asking mostly because this feature isn't documented in trouble.texi. The emergency escape (=3D emergency exit) feature is well-documented but I fear that won't help most users, terminal frames being rare these days. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 07:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174988475620029 (code B ref 78737); Sat, 14 Jun 2025 07:06:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 07:05:56 +0000 Received: from localhost ([127.0.0.1]:60042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQKxf-0005Cz-SQ for submit@debbugs.gnu.org; Sat, 14 Jun 2025 03:05:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50324) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQKxd-0005Ch-NI for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 03:05: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 1uQKxX-000592-Lr; Sat, 14 Jun 2025 03:05:47 -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=IkbQpgA/QpafK9nDq5Sr+C2xOIK2yP5uZJ/+TQYDYNg=; b=Y3lZycA+dxZn I6wVDr9E0En+wphSu5wq0XlYCCEfRH3MlRZMwBtY2agOVu18XUumOokgVBd7BA8jjGa74EfJ8WCSr AfWEKwyfJm0D5wYvBujA1+chDbkQ4iUlFNf6uPPgJR1oREgMTExT6A7X//YjgqwdzgS1yrS2co02a 59g3ofV9+DXSbIyypJELKXoUp+fZ81PpQtlZ9xwj4yzxzaTBKAd2lItUsuYUXxqfv9XzXd69cK74/ LvBKDgE/yQJInC0KsIVzzbOflsart8VijIFfyu8J0rz+t1paeCAimGpSW4Z80oZWhog1ZvR/rkRTN UBLr/Y02xXB2eq2gGPlpVQ==; Date: Sat, 14 Jun 2025 10:05:46 +0300 Message-Id: <865xgyu7jp.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Fri, 13 Jun 2025 14:07:20 -0400) References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <9EF7F59A-8131-4EB5-92B5-D7C805434C59@dancol.org> <86frg3ttxc.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Stefan Monnier > Cc: Daniel Colascione , pipcet@protonmail.com, > 78737@debbugs.gnu.org > Date: Fri, 13 Jun 2025 14:07:20 -0400 > > > My current understanding is that what you propose will cause some > > (most) programs to be interruptible with a single C-g, while some (in > > particular those which call read-event) will need two or more C-g to > > be interrupted. Is that correct? > > I think so, tho only for *some* of those which call `read-event`. If read-event always returns 7, then the "*some*" part is incorrect, as long as C-g was pressed while we are in read-event. > > If this is correct, then we need to decide whether this inconsistency > > (one C-g vs several) is tolerable. > > That inconsistency already exists in various places, such as if you use > `read-key`. Yes, but it's a known inconsistency, with which we lived for many years. We are now introducing a new inconsistency. This is a practical matter, not an academic one. Some people and some applications will be surprised, and some applications will not work as they did before. Telling them that we always had a similar inconsistency will not help. > I think what we need to decide is if the resulting overall > behavior is better (e.g. easier to describe and less error prone), and > if so, whether it's worth the incompatibility. Yes, we do need to make that decision. However: . we need first to agree on the design and the implementation of new code, and . we then need to describe the resulting behavior in clear enough terms for others to understand and reason about it Then we need to describe these changes on emacs-devel and see if the changes in behavior are acceptable by the community. > Of course, we could also make the change more backward-compatible by > renaming `read-event` to some new name and (re)defining `read-event` on > top of that new function. That's yet another possibility, yes. But given the original motivation (the problems in transient.el), I doubt if this is a viable solution. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 07:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174988518921447 (code B ref 78737); Sat, 14 Jun 2025 07:14:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 07:13:09 +0000 Received: from localhost ([127.0.0.1]:60077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQL4d-0005Zf-D3 for submit@debbugs.gnu.org; Sat, 14 Jun 2025 03:13:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:34934) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQL4Z-0005YT-LG for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 03:13:04 -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 1uQL4T-0005v7-93; Sat, 14 Jun 2025 03:12:57 -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=F7EgcAKT9u4niyZ5gCY4X1eu4dGQPyV1yRwe+gsYXWc=; b=hJ9YECyByQ+/ 5VLyct5Za4yB1GeCHXK2eYzGXLdyNkc16KaYQYT4x3AqzW4PyTuHJJcLwkV3Dt51lphM2A0OFdi97 X9orOb4OXTbhtirKIRONZGVaA3wLfmqFwg2ESc7Wveq6wG59kg294uRi+XfjeV+32YUVUjsG6IYU2 2Rq03W8uGEjgRWmjzCEghvJAHwQVf8ztnCAId9SXu286Lmd7mJW0nAn/hFftnCq3d6pw+li1ti1Rq 8qcfiP9102htskcR5+OVZ4JpXeLUWE+OXfCB54qIJnq0UIfii6jt/Ibm6L7v4Ds1uCck8IpD6iYvV 7lMOF99RWV0Jgk0k5jJZqQ==; Date: Sat, 14 Jun 2025 10:12:55 +0300 Message-Id: <864iwiu77s.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Fri, 13 Jun 2025 14:14:44 -0400) References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> <86y0twerm0.fsf@gnu.org> <86jz5ftuk8.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Stefan Monnier > Cc: dancol@dancol.org, 78737@debbugs.gnu.org, pipcet@protonmail.com > Date: Fri, 13 Jun 2025 14:14:44 -0400 > > >> > (while t > >> > (let (evt (read-event)) > >> > (do-something-with evt))) > >> > > >> > _can_ be interrupted? > >> > >> Usually the `(do-something-with evt)` part will offer some way to end > >> the loop. > > > > How? If read-event returns the character 7, then the information > > about the fact that C-g was typed is lost by the time we get to the > > do-something-with part, no? > > AFAIK that information is in `evt` and hence not lost. That's not what I see on the branch. read-event returns the character 7, a scalar. Or am I missing something? > Usually `do-something-with` will look at `evt` and do various things > depending on the key that was pressed and usually one of those options > lets you end what you were doing. > > Some code may assume they don't need to explicitly abort when `evt` is > 7 because they rely on the current behavior of `read-event`, but AFAIK > that behavior is not completely reliable (e.g. it depends on > `inhibit-quit` and sometimes timing), so if we want to encourage use of > that feature we should try and make it more reliable. So you are saying that, to be interruptible by a single C-g, a Lisp program that calls read-event will need to have code that quits under certain circumstances when read-event returns 7, is that right? Doesn't that mean we will now require every program that calls read-event to have such Lisp code, where it previously didn't? Pushing quitting to the application level is not something that will be appreciated by Lisp programmers, I think. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 07:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174988523321552 (code B ref 78737); Sat, 14 Jun 2025 07:14:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 07:13:53 +0000 Received: from localhost ([127.0.0.1]:60091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQL5N-0005bY-9a for submit@debbugs.gnu.org; Sat, 14 Jun 2025 03:13:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45442) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQL5K-0005bJ-UB for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 03:13:51 -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 1uQL5F-0005yA-EU; Sat, 14 Jun 2025 03:13:45 -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=WI6Bukb2gv9rAHKAXOncQdjZ3po5zxuAyC+gJYSUINM=; b=l3nW3Bco7wqk 3JZ0jvDh+QrJ4aghAWISYgq7alIR9eT1W6dNKnhhDgnE1h5Gw3vbPu+mv62H7ltycYWgiw4pS3cMq nCZshXAtjY8/DBuPRzcnpP1aUJ3jatOInGbMkKnmkUCH+HIA585MXeTzYtrcQUaNcubDCxTnIBfYE WyJoRgdEnBmYZdyNTRQi1awt8ThFumlMS21oIBMkuet6iQJ9OBLLkxoV+D9NW44yTSDpn9rq0wr6W kZBGeem2wEQqG/ZhsyiqQLf449BItktIVUGiB1ygTDwd1VJbeQfDpGzamZ5i+FZeI5OL8u1eeGaCn pl5qdO6/SNWImXVw1QE5/w==; Date: Sat, 14 Jun 2025 10:13:43 +0300 Message-Id: <8634c2u76g.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Fri, 13 Jun 2025 14:17:01 -0400) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Stefan Monnier > Cc: dancol@dancol.org, 78737@debbugs.gnu.org, pipcet@protonmail.com > Date: Fri, 13 Jun 2025 14:17:01 -0400 > > >> What is "emergency quit"? > > Something like `C-g C-g C-g`, tho we don't have that implemented, > > currently, AFAIK. > > I guess `kill -USR2` could count as well. Not as a single trigger, no: it isn't portable enough. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 07:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174988538622346 (code B ref 78737); Sat, 14 Jun 2025 07:17:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 07:16:26 +0000 Received: from localhost ([127.0.0.1]:60117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQL7q-0005oM-2J for submit@debbugs.gnu.org; Sat, 14 Jun 2025 03:16:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42834) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQL7n-0005o6-BG for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 03:16: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 1uQL7h-0006Jh-Jt; Sat, 14 Jun 2025 03:16:17 -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=s2RYqxr1nOatR/GIKXOkbbs/wdSQtqTyDfbmo8svAM0=; b=CRRUPbRTnNxQ 0SgutWUVFxXdPqnhpgSbAx6594r4uhugjCy1lyF59VPiQ/d9FlO5ksnyOM9A0DKUPexUE7GpL+6rZ jCXdKo4/v2KxZY/Mzo0MPzoI57opNvWIkp07o6+vA7tqGALdirlfAzn6KyDgJO/ZY+0aeP47se1vg DdumYabgWRxYdsisY2+UJeKMMrGhzn9ei+W6C5F65O9RPwEMtcS9sEiShunbYD0Wnf6XgxbFzkFCv k6OB+0WCikTicj5gh8OHBu3Nl9tRXegPevPk1T9wKTC+W+hENHPY5eVswBXpyWDMUKeO6E9dMZzTk I99XMV8AQbPha7kfpfB6LQ==; Date: Sat, 14 Jun 2025 10:16:15 +0300 Message-Id: <861prmu728.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87ikkzwlbu.fsf@protonmail.com> (message from Pip Cet on Fri, 13 Jun 2025 18:25:13 +0000) References: <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> <87ikkzwlbu.fsf@protonmail.com> X-Spam-Score: -2.3 (--) 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: Fri, 13 Jun 2025 18:25:13 +0000 > From: Pip Cet > Cc: Eli Zaretskii , dancol@dancol.org, 78737@debbugs.gnu.org > > "Stefan Monnier" writes: > > >> What is a "normal quit"? > > > > A single C-g. > > > >> What is "emergency quit"? > > > > Something like `C-g C-g C-g`, tho we don't have that implemented, > > currently, AFAIK. > > It's implemented. See handle_interrupt in keyboard.c: > > /* Request quit when it's safe. */ > int count = NILP (Vquit_flag) ? 1 : force_quit_count + 1; > force_quit_count = count; > if (count == 3) > Vinhibit_quit = Qnil; > Vquit_flag = Qt; That's not "emergency quit", that's part of "emergency exit". A different, though related, feature. > The "emergency" part is clearing the inhibit-quit flag when > force_quit_count reaches 3. The bug is that it should be >= 3, and the > questionable design feature is that we should reset the counter if > Vquit_flag and Vinhibit_quit are both nil, not just based on Vquit_flag. It isn't a bug, because emergency exit happens when the count is 2. There's a reason why I suggested to leave the emergency exit feature alone for now. Mixing it with this discussion just muddies the waters and adds to confusion and misunderstandings. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 07:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174988745432261 (code B ref 78737); Sat, 14 Jun 2025 07:51:01 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 07:50:54 +0000 Received: from localhost ([127.0.0.1]:60930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQLfB-0008OH-Jn for submit@debbugs.gnu.org; Sat, 14 Jun 2025 03:50:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52092) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQLf8-0008O2-KF for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 03:50:51 -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 1uQLf1-0001XT-AM; Sat, 14 Jun 2025 03:50:43 -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=H6vRUgZutKJ/Oc1XuSPy54bxyDMMGyNIJHtUXimnV+4=; b=sdl/iImsRJ70 0PL/uxifrtbOQtxEL60XdQL6r20Z9P1Pu+/M9nCEY+xYkmeI4KvCboS8ILCKz5FxuMUkj6iHop9ip iSNvUoi2PISTK5/E3NDwvm27xJUlK0fw2CAbHenXo7V6CIO+Mp5U2AFcZ4XYXW4k6auGRqhdxLzFa B1FppD1cqiT/K2T6QaDD/fDzIA5ZJR3YSewqdhMqp2j2Cd8peBs7c7jLkofDtTmt0GMC98tUJihX5 4d9i4EGyfSUzSZYd0aOppOh6Vt6w0VpMcve8KVhiwGkZ6kFASdSS9Y+RNLy8SswcmdSrfxzT6TORi LYR0c1LWByRvXmYCtohV+Q==; Date: Sat, 14 Jun 2025 10:50:41 +0300 Message-Id: <86zfeasqwe.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Fri, 13 Jun 2025 14:38:22 -0400) References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <9EF7F59A-8131-4EB5-92B5-D7C805434C59@dancol.org> <86frg3ttxc.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Fri, 13 Jun 2025 14:38:22 -0400 > From: Daniel Colascione > CC: monnier@iro.umontreal.ca, pipcet@protonmail.com, 78737@debbugs.gnu.org > > On June 13, 2025 1:47:43 PM EDT, Eli Zaretskii wrote: > >My current understanding is that what you propose will cause some > >(most) programs to be interruptible with a single C-g, while some (in > >particular those which call read-event) will need two or more C-g to > >be interrupted. Is that correct? > > Yes. Good. > However, it looks right now like the class of program that has to be quit with a repeated C-g is extremely small. I've seen only contrived examples so far. Most programs do something with the result of calling read-event, and when they see C-g, either break out of their dispatch loop or do a C-g appropriate thing. > > Things using low level input events like that, however, tend to be either old or specialized. > > The most common code paths (e.g. isearch, transient, map-y-or-n-p, etc.) with dispatch loops already use higher level tools like read-key, read-char-from-minibuffer, or transient keymaps and so get C-g handled as an input event anyway. > > Has anyone complained that (while t (read-key)) doesn't admit keyboard quitting? > > In practice, based on experience so far, there's no practical need to press C-g any more often than one does on mainline. > > >If this is correct, then we need to decide whether this inconsistency > >(one C-g vs several) is tolerable. > > I think it's correct only in theory. Maybe I'm wrong and there's some undiscovered case that this breaks. It's to discover these cases that it would be nice to test the branch and merge it to mainline. We can always put it behind a feature flag. I don't think we can dismiss use cases just because they are rare. When we get a bug report about some regression, we try to fix the regression regardless of how frequent the recipe is. We do sometimes decide not to fix such bugs, and in those cases we might bring up arguments about importance and frequency of the situation. But first we try to fix the bug without considering that. So if we are going to have a policy of disregarding such regressions in these cases, we need to see a broad agreement to it. > >Thanks, but that doesn't answer my question, which is specifically > >about the effect of C-g on Lisp programs, whether they call read-event > >or don't call it. > > Lisp programs that don't call read-event, read-char, or read-char-exclusive don't see a change in behavior except for how, once we implement the repeated C-g work, users will be able to break out of loops like (while t (read-key)) by pressing C-g multiple times. > > I have yet to see a real program that does something like this, much less one that depends on bricking quit functionality in the user's Emacs session. > > Lisp programs that do call these low level functions see a contract change, as I detailed in my previous messages. I understand that Lisp programs which do call those low-level functions will need to either accept that they cannot be interrupted by a single C-g, or add some Lisp to quit when they receive a keyboard input event that's equal to quit-char, is that right? If so, we will need to clearly identify and document the low-level functions affected by this. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 07:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498877741316 (code B ref 78737); Sat, 14 Jun 2025 07:57:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 07:56:14 +0000 Received: from localhost ([127.0.0.1]:32818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQLkI-0000KJ-Ts for submit@debbugs.gnu.org; Sat, 14 Jun 2025 03:56:13 -0400 Received: from mail-10628.protonmail.ch ([79.135.106.28]:46837) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQLkG-0000Jj-EY for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 03:56:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1749887761; x=1750146961; bh=coyNW9MZ1BeZMwJJwSfEbTA+smMEXyYfknRi4GJ9s2Q=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=jpb2NvkQa/KM275Ut1sd6+DZGJSaM2xAtwYlw6kD1Vd4O/Cpk7BJWKr1+FGpWWH5n a/+I1/HdBDYbOFJroS72k87gu3mNGAiCSwMbeRJBb4wOCACf4wVmL0UnDRznVAiaee kNaVcoOilP6CtZSy6R1rBr6seDVprXsF6HnKhi7J7JmQ4cpgsxP+KHb8QqdmuKnz9J DCmROJkloXjf7lqhZeq5ULQ9SbykSdoIoGwipugMx9Ct5BBQP0s3A9E6JGo8KcvEOf gRtFNli7B+C1cF9rYCu25sx1R0WgSNa9QFciDbVRL2eRCWzbZMIYdqtIWO9O17+Hh2 acxNVwmJ191ww== Date: Sat, 14 Jun 2025 07:55:54 +0000 From: Pip Cet Message-ID: <87sek2vjst.fsf@protonmail.com> In-Reply-To: <861prmu728.fsf@gnu.org> References: <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> <87ikkzwlbu.fsf@protonmail.com> <861prmu728.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 1679441ec4d99bc92828dcdc72b9dd6b6e051dab MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Eli Zaretskii" writes: >> Date: Fri, 13 Jun 2025 18:25:13 +0000 >> From: Pip Cet >> Cc: Eli Zaretskii , dancol@dancol.org, 78737@debbugs.gnu.o= rg >> >> "Stefan Monnier" writes: >> >> >> What is a "normal quit"? >> > >> > A single C-g. >> > >> >> What is "emergency quit"? >> > >> > Something like `C-g C-g C-g`, tho we don't have that implemented, >> > currently, AFAIK. >> >> It's implemented. See handle_interrupt in keyboard.c: >> >> /* Request quit when it's safe. */ >> int count =3D NILP (Vquit_flag) ? 1 : force_quit_count + 1; >> force_quit_count =3D count; >> if (count =3D=3D 3) >> =09Vinhibit_quit =3D Qnil; >> Vquit_flag =3D Qt; > > That's not "emergency quit", that's part of "emergency exit". A > different, though related, feature. Sorry, still being dense. This code is not reached on text terminals, so it's not part of what trouble.texi calls the Emergency Escape mechanism. I thought you were using "emergency exit" to refer to the Emergency Escape feature, but the above suggests that "emergency exit" includes both the Emergency Escape and triple-C-g behavior on GUI terminals. I'd like a term for just the latter. Triple C-g on a GUI terminal clears inhibit-quit and quits, breaking out of loops such as: (let ((inhibit-quit t)) (while t)) This: 1. requires *three* C-g presses 2. does not trigger an Emergency Escape or exit Emacs 3. is unreachable on text terminals Since this behavior does not exit Emacs, I thought it would not count as part of the "emergency exit" feature. >> The "emergency" part is clearing the inhibit-quit flag when >> force_quit_count reaches 3. The bug is that it should be >=3D 3, and th= e >> questionable design feature is that we should reset the counter if >> Vquit_flag and Vinhibit_quit are both nil, not just based on Vquit_flag. > > It isn't a bug, because emergency exit happens when the count is 2. No, nothing special happens when the count reaches 2. These two are mutually exclusive: The code incrementing force_quit_count is unreachable on text terminals. The code implementing the Emergency Escape feature is unreachable on GUI terminals. static void handle_interrupt (bool in_signal_handler) { char c; cancel_echoing (); /* XXX This code needs to be revised for multi-tty support. */ if (!NILP (Vquit_flag) && get_named_terminal (dev_tty)) { } else { /* Request quit when it's safe. */ int count =3D NILP (Vquit_flag) ? 1 : force_quit_count + 1; <-- on te= xt terminals, Vquit_flag is nil! force_quit_count =3D count; if (count =3D=3D 3) =09Vinhibit_quit =3D Qnil; Vquit_flag =3D Qt; } ... } So, on GUI frames, a double C-g will leave force_quit_count set to 2, but it will not perform an Emergency Escape, and it will not clear inhibit-quit. Nothing special happens when force_quit_count reaches 2. The third C-g, assuming quit-flag is still set, will clear inhibit-quit, set the quit-flag again, and thus trigger a "special kind of quit". I'm looking for a name for it. I note that this triple-C-g behavior is documented only in the code; it's missing from trouble.texi. diff --git a/doc/emacs/trouble.texi b/doc/emacs/trouble.texi index 45f15c7dd0d..33c97352f7c 100644 --- a/doc/emacs/trouble.texi +++ b/doc/emacs/trouble.texi @@ -83,6 +83,10 @@ Quitting actually executed as a command if you type it while Emacs is waiting for input. In that case, the command it runs is @code{keyboard-quit}. =20 + On graphical terminals, you may be able to quit by typing @kbd{C-g} +three times, even when an ordinary @kbd{C-g} doesn't work. +@xref{Feature X}. + On a text terminal, if you quit with @kbd{C-g} a second time before the first @kbd{C-g} is recognized, you activate the emergency-escape feature and return to the shell. @xref{Emergency Escape}. @@ -157,7 +161,8 @@ Lossage * Memory Full:: How to cope when you run out of memory. * Crashing:: What Emacs does when it crashes. * After a Crash:: Recovering editing in an Emacs session that cras= hed. -* Emergency Escape:: What to do if Emacs stops responding. +* Feature X:: What to do if Emacs stops responding. +* Emergency Escape:: What to do if Emacs stops responding on a text t= erminal. * DEL Does Not Delete:: What to do if @key{DEL} doesn't delete. @end menu =20 @@ -400,6 +405,22 @@ After a Crash which does not already exist; if the file does exist, the script does not make a backup of its old contents. =20 +@node Feature X +@subsection Feature X +@cindex feature x + +@c This works only if all terminals are graphical terminals; mixed +@c text/GUI terminal sessions use the Emergency Escape feature. + + On graphical terminals, typing @kbd{C-g} three times in a row while +Emacs is not responding will clear the @code{inhibit-quit} flag. This +allows Emacs to recover from being stuck in certain kinds of loops. + + After using this feature, Emacs will appear to have processed an +ordinary quit, but you should exit and restart Emacs. This is because +forcibly clearing the @code{inhibit-quit} flag may have left Emacs in an +inconsistent state. + @node Emergency Escape @subsection Emergency Escape @cindex emergency escape Obviously, we should replace "feature X" by something else. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 07:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498877801338 (code B ref 78737); Sat, 14 Jun 2025 07:57:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 07:56:20 +0000 Received: from localhost ([127.0.0.1]:32820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQLkR-0000LV-L2 for submit@debbugs.gnu.org; Sat, 14 Jun 2025 03:56:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37928) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQLkG-0000K2-JV for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 03:56:11 -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 1uQLkA-0002DL-3F; Sat, 14 Jun 2025 03:56:02 -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=n+vIP+trYiJ/pofQ4cTKzsV1Zz8u/anAG4V7Ea+C30c=; b=O/AWeHQ8+1vy n9F5Fe7d7oe9js7B36r3qGFwRi280oHPxxGFJ0p6UR66x0uP602eS9tLfXARjCtxqAVVliFf5umZN c8ExtDSXkX5xI7l1XF+nouXTGHYlNSoL9Ms3JUNmbREUsjb/3bmwBSFBjWhTK0ov8qIM4Lm8Opb8H 0KCIOVtdV/XOr6h+624jHxBHNa/zXZpIYTLYDG689IaYjAUmfgmws4QzKMfVQghiBm5pG45hZHBz4 Z61Sk68/aEFEJ4WZ/jrvYEJ7wSCExEUvivVdOnzRBk0OGGoHpc27y6/dMq+pIg8JcjMxyjOgh7WKs 536WMn9ZkVQh4ee7vLqcRQ==; Date: Sat, 14 Jun 2025 10:55:57 +0300 Message-Id: <86y0tusqnm.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <4BCDF146-4265-4070-9223-E6A6902F6BC9@dancol.org> (message from Daniel Colascione on Fri, 13 Jun 2025 15:07:51 -0400) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> <4BCDF146-4265-4070-9223-E6A6902F6BC9@dancol.org> X-Spam-Score: -2.3 (--) 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: Fri, 13 Jun 2025 15:07:51 -0400 > From: Daniel Colascione > CC: 78737@debbugs.gnu.org, pipcet@protonmail.com > > On June 13, 2025 2:16:08 PM EDT, Stefan Monnier wrote: > >> What is a "normal quit"? > > > >A single C-g. > > > >> What is "emergency quit"? > > > >Something like `C-g C-g C-g`, tho we don't have that implemented, > >currently, AFAIK. > > > How about this terminology? > > C-g --- normal quit > > C-g C-g C-g --- urgent quit (breaks out of read-event. should probably break out of redisplay too?) Breaking out of redisplay should remain an opt-in behavior, like it is now on the branch. When turned on, I'm okay with having it activated with several C-g presses. > C-g C-g C-g C-g C-g C-g --- emergency quit. ignores inhibit-quit. good chance of horking your Emacs by violating atomicity assumptions. Display "are you sure?" message before final C-g. This seems to ignore the "emergency exit" feature we have today. I wouldn't want to lose that as well. Or did you mean to leave that activated by "C-g C-g"? If the latter, wouldn't we be prone to sometimes activating the emergency exit instead of the "urgent quit"? From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 08:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org, monnier@iro.umontreal.ca, owinebar@gmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498888586006 (code B ref 78737); Sat, 14 Jun 2025 08:15:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 08:14:18 +0000 Received: from localhost ([127.0.0.1]:33216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQM1p-0001YZ-2Z for submit@debbugs.gnu.org; Sat, 14 Jun 2025 04:14:18 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47496) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQM1l-0001YA-Mj for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 04:14:14 -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 1uQM1f-0004TV-9Y; Sat, 14 Jun 2025 04:14:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=GGzYNA1p5cWowvnzJfcm93vSS3mTcyigkP27yxEBIuw=; b=pZAm03SM7CWCUl/yGxsT wJn50ReegctM528l5t3hcH/cXyuAq+L8qBNwks4JFYpr2iRyPNuZzbhFxI61g4wUECGYhmso+n351 VMOS0Vkkq7AeyaEUUo+ZWM/RiSYCk4Do6mubm9u1J/B5mTblejUfWCd4HgUOR80ZeQ51XnyPw4Hnf DD4AtUcQgcczISjRlGfHeBxkOsyWnx0888srpJsDON+h4OADQIH5L1DRX9PRJA+lfvraRIXZJQ0Qj 7sg04VzgcqP6V5VixqPCzvUTXa78TQn1tfMhef4JQ8zbLSYrrUyhT2aGOspGyIGQCLwxSn/SO1lWL vQ0yYndzYXjjRg==; Date: Sat, 14 Jun 2025 11:14:04 +0300 Message-Id: <86tt4isptf.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Sat, 14 Jun 2025 05:43:41 +0200) References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) 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 (---) > From: Gerd Möllmann > Cc: Daniel Colascione , 78737@debbugs.gnu.org, Eli > Zaretskii , Pip Cet , Lynn > Winebarger > Date: Sat, 14 Jun 2025 05:43:41 +0200 > > Stefan Monnier writes: > > >>> We already have something like that. :-) read-event already runs the > >>> events it reads through special-event-map, right? > >> Entirely unrelated, I just came across this because I searched for > >> read-event. Let me just mention that read-event does not respect > >> input-decode-map. This is a problem on ttys, see bug#75886. > > > > Currently the only "decoding" we have to turn the TTY input bytes into > > events is limited to the keyboard-coding-system thingy. 🙁 > > > > Maybe I should have implemented `input-decode-map` directly inside > > `read-event`, but I think it goes contrary to the design. > > > > It's usually better to change the users to use a higher-level function > > instead, such as `read-key`. > > > > Admittedly, if you want to recognize a quit event encoded as an escape > > sequence, that's not going to help you because we need/want those events > > to be decoded at as-low a level as we can. 🙁 > > I'd deprecate read-event TBH. If we want to do this, we should start by removing it from our own sources. Currently, we use it in around 80 places. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 08:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174988984910589 (code B ref 78737); Sat, 14 Jun 2025 08:31:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 08:30:49 +0000 Received: from localhost ([127.0.0.1]:33514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQMHn-0002kY-Oe for submit@debbugs.gnu.org; Sat, 14 Jun 2025 04:30:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51976) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQMHk-0002jz-W3 for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 04:30:45 -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 1uQMHa-0006nj-VX; Sat, 14 Jun 2025 04:30:36 -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=mXLqqFQqo/lpxo33Ix2H+xCLKFNQSPbA+N3iNHL8+04=; b=fD6d+7963eDU KKzPdPdxn2LzZvVFT5zmG/lak9CTECxrcEYYIRNVHwSdy1Tzv6eAy3/tluRO+6lmm09e3JdG38WJ9 faqZl3ehkfBT0fen+Brpf0bW7snMV5zVW7cR5ahx2MVfwM8r1et9cf8Avz6Qv8dIJk33tlJd7kOCd t3r5RlY0S4J2E3XCTmDRYPlvVGEmN7qAGHwL6UTA64bucWJ6/oijr2hv3VixaOflkY/imcyN1ktCy /HNk5SmBE8vEvisUi0xNrAvD0u+Yv/s3nIFEmVTnxyIiVIupNKPga4H+ksUrDpAE2OcuJSERR29e1 ztlZs4StnZxjxv1YG51etg==; Date: Sat, 14 Jun 2025 11:30:31 +0300 Message-Id: <86sek2sp20.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87y0tuvn15.fsf@protonmail.com> (message from Pip Cet on Sat, 14 Jun 2025 06:46:03 +0000) References: <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <868qluu9ev.fsf@gnu.org> <87y0tuvn15.fsf@protonmail.com> X-Spam-Score: -2.3 (--) 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: Sat, 14 Jun 2025 06:46:03 +0000 > From: Pip Cet > Cc: Stefan Monnier , dancol@dancol.org, 78737@debbugs.gnu.org > > "Eli Zaretskii" writes: > > > "Emergency exit" (not "emergency quit", which never existed in Emacs) > > is the feature whereby typing more than 1 C-g would pop the question > > whether to exit Emacs and if so, whether to dump core. > > Sorry if I'm being dense, but just to recap: > > "Emergency exit" works in sessions that have a terminal frame. In such > sessions, the code manipulating force_quit_count is never reached. > > In GUI sessions, this code is reached, and hitting C-g three times while > quit-flag is set will perform a special kind of quit, clearing > inhibit-quit. > > IIUC, you object to calling this special kind of quit "emergency quit", > and would prefer to call it something else. > > Is that right? What's the preferred term for this special kind of quit? I don't know. This feature is not currently documented in the manual, so I don't think we have a term for it. We don't even advertise it anywhere, AFAICT. > I'm asking mostly because this feature isn't documented in trouble.texi. > The emergency escape (= emergency exit) feature is well-documented but I > fear that won't help most users, terminal frames being rare these days. I would like to see the emergency exit feature work on GUI frames as well, if that's feasible. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 08:50:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, Pip Cet , dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174989095614398 (code B ref 78737); Sat, 14 Jun 2025 08:50:03 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 08:49:16 +0000 Received: from localhost ([127.0.0.1]:33682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQMZf-0003k9-MR for submit@debbugs.gnu.org; Sat, 14 Jun 2025 04:49:16 -0400 Received: from mout01.posteo.de ([185.67.36.65]:41873) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQMZc-0003js-Hn for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 04:49:13 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 6CC35240027 for <78737@debbugs.gnu.org>; Sat, 14 Jun 2025 10:49:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=1984.ea087b; t=1749890945; bh=cVZexkLiugGZPo/XZZUM1NyzuyskbnGD1/39IAfEfT4=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=Ysgu2Y9Y9bn0awz2dKZkDL02glVFEVnWVI8UcjQHiiY6L6l15JUpnslDXVdPYB/Mc K91+4Uyosgpf1c6UyquM3DkmESQ0Nj3JK9jh2mR58cSFIPBd27TCCZvzDq2YsVDIDR jyx747rfl5cmkSpxKHY0qAsH0y66PZ4DhNcs9wiR8D0dbne6Aikjm5/7XCuqgeTq33 GPcxjw1htqgQ0BumdkWahvxnRj2xCF3s/GKw7B8bDn8YLdoyj+ymNSaTltKld3oq2S cArkmvIjbrcbyu7F8INHI9Mhp1ubzIq9AQ0ef+WoRC4jrHEStlIJ3ff98cwayNqgwt IvWMkwyZFRFTRUYdJXhes8gKZvJnPsUpdHd7mvMCcpK2zdC7w3EHyYk6OJ+F46GoP/ T/Kha55X3vAvb3xFOULJcsccS9ADesD+ORHlSeEh1eWeVQ0By8YBLYaLndpvCqKbQp J00bUVUpxpxY9cO7x5aV1CGwSXc7xQ3GM+Yy4NXKNzaPbwt1gOJ Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4bK90q66N2z6v1R; Sat, 14 Jun 2025 10:48:59 +0200 (CEST) From: Ihor Radchenko In-Reply-To: <86sek2sp20.fsf@gnu.org> References: <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <868qluu9ev.fsf@gnu.org> <87y0tuvn15.fsf@protonmail.com> <86sek2sp20.fsf@gnu.org> Date: Sat, 14 Jun 2025 08:47:41 +0000 Message-ID: <87v7oy3e1e.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) 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 (---) Eli Zaretskii writes: >> I'm asking mostly because this feature isn't documented in trouble.texi. >> The emergency escape (= emergency exit) feature is well-documented but I >> fear that won't help most users, terminal frames being rare these days. > > I would like to see the emergency exit feature work on GUI frames as > well, if that's feasible. +1 FYI, I independently re-implemented (without knowing) a similar feature for Org mode (see `org-element--cache-interrupt-C-g' and `org-element--cache-interrupt-C-g-max-count' in org-element.el) Note that it is an example when Elisp code needs some cleanup if emergency exit is requested: (when (and inhibit-quit org-element--cache-interrupt-C-g quit-flag) (when quit-flag (cl-incf org-element--cache-interrupt-C-g-count) (setq quit-flag nil)) (when (>= org-element--cache-interrupt-C-g-count org-element--cache-interrupt-C-g-max-count) (setq quit-flag t) (setq org-element--cache-interrupt-C-g-count 0) (org-element-cache-reset) (error "org-element: Parsing aborted by user. Cache has been cleared. If you observe Emacs hangs frequently, please report this to Org mode mailing list (M-x org-submit-bug-report)")) (message (substitute-command-keys "`org-element--parse-to': Suppressed `\\[keyboard-quit]'. Press `\\[keyboard-quit]' %d more times to force interruption.") (- org-element--cache-interrupt-C-g-max-count org-element--cache-interrupt-C-g-count))) -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 08:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174989127615874 (code B ref 78737); Sat, 14 Jun 2025 08:55:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 08:54:36 +0000 Received: from localhost ([127.0.0.1]:33825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQMep-00047y-RH for submit@debbugs.gnu.org; Sat, 14 Jun 2025 04:54:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42504) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQMen-00047i-Ad for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 04:54:34 -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 1uQMeg-00015U-Kn; Sat, 14 Jun 2025 04:54:26 -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=dRZ7ly5TaNq/DOu+c2JBo86UrcNp8BT32PQk5wLvL2k=; b=kK30po7RelGb qQwZa8FVV/yZNCj9645tbyFQRgpnfU3Y5moiOGttpOSbiUy0W77wXRZyJYCHnumJE8Z3Il15vnTpX LSd3XY4K4eyaQGOwSThnYWixBXD8vhNunngeuhHVeQ1NfhQBpGKoYJGudH/Fxt8LI+PuZkM+cbhy2 nDt/iAPbdmBajKldzFFGQZrKD19mC7TJED26m1/nz61pDrnh49SO5ebV6dj90IQJQXtL8Ag3bK/o3 Lx2nRaQ6mSD+3nMtHrjtci19UUR6K+JMk2OIciRBXUFrUt9VlaoZMtAMYVetqcRkTisMZQQyqc1bD XzOOTO0sS+ENDbqnJGFK7A==; Date: Sat, 14 Jun 2025 11:54:25 +0300 Message-Id: <86qzzmsny6.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87sek2vjst.fsf@protonmail.com> (message from Pip Cet on Sat, 14 Jun 2025 07:55:54 +0000) References: <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> <87ikkzwlbu.fsf@protonmail.com> <861prmu728.fsf@gnu.org> <87sek2vjst.fsf@protonmail.com> X-Spam-Score: -2.3 (--) 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: Sat, 14 Jun 2025 07:55:54 +0000 > From: Pip Cet > Cc: monnier@iro.umontreal.ca, dancol@dancol.org, 78737@debbugs.gnu.org > > "Eli Zaretskii" writes: > > >> /* Request quit when it's safe. */ > >> int count = NILP (Vquit_flag) ? 1 : force_quit_count + 1; > >> force_quit_count = count; > >> if (count == 3) > >> Vinhibit_quit = Qnil; > >> Vquit_flag = Qt; > > > > That's not "emergency quit", that's part of "emergency exit". A > > different, though related, feature. > > Sorry, still being dense. This code is not reached on text terminals, > so it's not part of what trouble.texi calls the Emergency Escape > mechanism. I thought you were using "emergency exit" to refer to the > Emergency Escape feature I was. > but the above suggests that "emergency exit" > includes both the Emergency Escape and triple-C-g behavior on GUI > terminals. It doesn't. The triple-C-g thing is not documented at all. > Triple C-g on a GUI terminal clears inhibit-quit and quits, breaking out > of loops such as: > > (let ((inhibit-quit t)) > (while t)) Btw, the triple-C-g doesn't break this on Windows in a GUI session. handle_interrupt is not called at all on Windows when I press C-g. > This: > > 1. requires *three* C-g presses > 2. does not trigger an Emergency Escape or exit Emacs > 3. is unreachable on text terminals If we want to adverse this, we need to document it in the same place as the emergency exit. > Since this behavior does not exit Emacs, I thought it would not count as > part of the "emergency exit" feature. Indeed, it doesn't. > >> The "emergency" part is clearing the inhibit-quit flag when > >> force_quit_count reaches 3. The bug is that it should be >= 3, and the > >> questionable design feature is that we should reset the counter if > >> Vquit_flag and Vinhibit_quit are both nil, not just based on Vquit_flag. > > > > It isn't a bug, because emergency exit happens when the count is 2. > > No, nothing special happens when the count reaches 2. On TTY frames, it does, doesn't it? > These two are mutually exclusive: > > The code incrementing force_quit_count is unreachable on text terminals. > > The code implementing the Emergency Escape feature is unreachable on GUI > terminals. OK, so once we've established that, what's your point? > I note that this triple-C-g behavior is documented only in the code; > it's missing from trouble.texi. Yes, but the correct place to document it is in the same section where the emergency exit is described. And talking about inhibit-quit in the user manual is wrong, because users aren't expected to know about that. And finally, if we want to advertise this, we had better made it work on all supported platforms. Last, but not least, this is not directly related to the main part of this discussion, which is about being able to interrupt Lisp programs by a single C-g. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 09:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: pipcet@protonmail.com Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174989233620868 (code B ref 78737); Sat, 14 Jun 2025 09:13:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 09:12:16 +0000 Received: from localhost ([127.0.0.1]:34239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQMvv-0005QV-Gk for submit@debbugs.gnu.org; Sat, 14 Jun 2025 05:12:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35434) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQMvs-0005QD-NH for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 05:12:13 -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 1uQMvl-0003DU-SN; Sat, 14 Jun 2025 05:12:05 -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=9yTVaEw9w3JkukD2TzubHMz8klbAwgrlFMEJAPwZX3M=; b=hDbd7VNNAnhN v94C6hOkPBffjlNXZ+6alR8DFwdcGtG2VNTR4zWDMGytiFoMVXneqm0XKn2TSlWS3Bam/NJXETXcT ysiijCx7CaOkI5CQZ9aPlKFZm+u2ppB9wcH/2mIfak3QQyPilVhWkc+3ipvKh75d07UKnjtFU++V2 H4cMAS8NgRB7XOgHhUwwuGuAQEbR9fXL0oM1wzrBc86UUov+8uBoSnrfxoX9BfSf4lhtnX4Df19Xj /4X3CE7E4eCUQcT8hY8jx23wd7WJsDacZVc48LSvH8U1X9rqYdoJIwtK9AquVD78i8II5NU0QUMUJ ql/XonwzfhQ6BuO0qHMxwA==; Date: Sat, 14 Jun 2025 12:12:03 +0300 Message-Id: <86plf6sn4s.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86sek2sp20.fsf@gnu.org> (message from Eli Zaretskii on Sat, 14 Jun 2025 11:30:31 +0300) References: <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <868qluu9ev.fsf@gnu.org> <87y0tuvn15.fsf@protonmail.com> <86sek2sp20.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca > Date: Sat, 14 Jun 2025 11:30:31 +0300 > From: Eli Zaretskii > > > "Emergency exit" works in sessions that have a terminal frame. In such > > sessions, the code manipulating force_quit_count is never reached. > > > > In GUI sessions, this code is reached, and hitting C-g three times while > > quit-flag is set will perform a special kind of quit, clearing > > inhibit-quit. > > > > IIUC, you object to calling this special kind of quit "emergency quit", > > and would prefer to call it something else. > > > > Is that right? What's the preferred term for this special kind of quit? > > I don't know. It seems this feature was originally known as "immediate quit". At some point the immediate_quit variable itself was removed, but the term seems appropriate regardless. So I suggest that's how we call it. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 09:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: pipcet@protonmail.com Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174989241021033 (code B ref 78737); Sat, 14 Jun 2025 09:14:01 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 09:13:30 +0000 Received: from localhost ([127.0.0.1]:34247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQMx8-0005TA-8j for submit@debbugs.gnu.org; Sat, 14 Jun 2025 05:13:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40154) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQMx5-0005St-QX for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 05:13:28 -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 1uQMx0-0003L9-Gm; Sat, 14 Jun 2025 05:13:22 -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=0RVr0Aq5Jx+KhUJPFx2FchSzvg7qwexOID+QuTLRFwo=; b=RV8DtPMtWIzT cdkLxo57KkVB8rIo7F9/BNo/9t/oX68CKuqbG28rDYhJI3R/6ppyC3f9mbV5iZGzv5frKDxinQoLx B00lcsJKPlRV8BmUvRuR0RJ6TZHcw3WNL3WXWuyS96/F9h4Pm/Dy5CcU/dYxCBq/OJEWoIg8R6NaP 2ZwxpeRA9Jo5vr12LpaM+XAKokk95Z14K2QVbDmc6IqIIIwIyogkeRXqWPJ9BhgQoeP4wkzuL+v0t j6m7vo1ry16AsteG4+dkd9cD+TJG2/XqKbP3mrvB6X8f7cCuwkBlrhMTNG7pOIoV3AIww4DoNNTUn k2oIiMLaLgocVh16rF383A==; Date: Sat, 14 Jun 2025 12:12:57 +0300 Message-Id: <86o6uqsn3a.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <86qzzmsny6.fsf@gnu.org> (message from Eli Zaretskii on Sat, 14 Jun 2025 11:54:25 +0300) References: <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> <87ikkzwlbu.fsf@protonmail.com> <861prmu728.fsf@gnu.org> <87sek2vjst.fsf@protonmail.com> <86qzzmsny6.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > Cc: 78737@debbugs.gnu.org, dancol@dancol.org, monnier@iro.umontreal.ca > Date: Sat, 14 Jun 2025 11:54:25 +0300 > From: Eli Zaretskii > > > Triple C-g on a GUI terminal clears inhibit-quit and quits, breaking out > > of loops such as: > > > > (let ((inhibit-quit t)) > > (while t)) > > Btw, the triple-C-g doesn't break this on Windows in a GUI session. > handle_interrupt is not called at all on Windows when I press C-g. I attempted to fix that now, on master. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 10:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Pip Cet Cc: 78737@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174989669831701 (code B ref 78737); Sat, 14 Jun 2025 10:25:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 10:24:58 +0000 Received: from localhost ([127.0.0.1]:34544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQO4I-0008FE-4t for submit@debbugs.gnu.org; Sat, 14 Jun 2025 06:24:58 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:39710) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQO4F-0008F5-DC for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 06:24:56 -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=u+Wc6lO9P7Uku9OOiJI2QVrba5Dv9WZg/j/fDE2qe8I=; b=ZIdjxUFCYQavKnMzRTsOpraqYI CTKo765uR+wvkQvnbxwrQNAAkGxozzci3VnbdS1BpfkmG3kW37OM2HZWrY8egm40utwZU7pzPbQC2 64G366RKcF9GWfGX2fxTxqSg/B0KIx7gKwhElVgR6wPT76yyGcU9Z1sHE7B5D6grRHOIR2nrBhTLn NFM1deuyfu2XkCHqwLQZso+xxeLeMFXeBm4E3PxKVFCjpW04/hf+EKWfDVIOTP6wudDR+ahGJsVjx /Cq76bQPI6GsBd2VBSKqDt9ZwZegWIWcJrCGfNkph1XkoQiTTV4ol+WibFJFzBCmyfTvh8TllfKbH eoqZr3Yg==; Received: from 2603-9001-4203-1ab2-a30c-ca1e-de1e-2c75.inf6.spectrum.com ([2603:9001:4203:1ab2:a30c:ca1e:de1e:2c75]:47876 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 1uQO2j-00Bymw-0J; Sat, 14 Jun 2025 06:23:21 -0400 Date: Sat, 14 Jun 2025 06:24:40 -0400 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <86qzzmsny6.fsf@gnu.org> References: <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> <87ikkzwlbu.fsf@protonmail.com> <861prmu728.fsf@gnu.org> <87sek2vjst.fsf@protonmail.com> <86qzzmsny6.fsf@gnu.org> Message-ID: <5A8BCAE5-9BD2-401D-897B-FD3A0D8EEBDA@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 14, 2025 4:54:25 AM EDT, Eli Zaretskii wrote: >> Date: Sat, 14 Jun 2025 07:55:54 +0000 >> From: Pip Cet >> Cc: monnier@iro=2Eumontreal=2Eca, dancol@dancol=2Eorg, 78737@debbugs=2E= gnu=2Eorg >>=20 >> "Eli Zaretskii" writes: >>=20 >> >> /* Request quit when it's safe=2E */ >> >> int count =3D NILP (Vquit_flag) ? 1 : force_quit_count + 1; >> >> force_quit_count =3D count; >> >> if (count =3D=3D 3) >> >> Vinhibit_quit =3D Qnil; >> >> Vquit_flag =3D Qt; >> > >> > That's not "emergency quit", that's part of "emergency exit"=2E A >> > different, though related, feature=2E >>=20 >> Sorry, still being dense=2E This code is not reached on text terminals= , >> so it's not part of what trouble=2Etexi calls the Emergency Escape >> mechanism=2E I thought you were using "emergency exit" to refer to the >> Emergency Escape feature > >I was=2E > >> but the above suggests that "emergency exit" >> includes both the Emergency Escape and triple-C-g behavior on GUI >> terminals=2E > >It doesn't=2E The triple-C-g thing is not documented at all=2E > >> Triple C-g on a GUI terminal clears inhibit-quit and quits, breaking ou= t >> of loops such as: >>=20 >> (let ((inhibit-quit t)) >> (while t)) > >Btw, the triple-C-g doesn't break this on Windows in a GUI session=2E >handle_interrupt is not called at all on Windows when I press C-g=2E > >> This: >>=20 >> 1=2E requires *three* C-g presses >> 2=2E does not trigger an Emergency Escape or exit Emacs >> 3=2E is unreachable on text terminals > >If we want to adverse this, we need to document it in the same place >as the emergency exit=2E > >> Since this behavior does not exit Emacs, I thought it would not count a= s >> part of the "emergency exit" feature=2E > >Indeed, it doesn't=2E > >> >> The "emergency" part is clearing the inhibit-quit flag when >> >> force_quit_count reaches 3=2E The bug is that it should be >=3D 3, = and the >> >> questionable design feature is that we should reset the counter if >> >> Vquit_flag and Vinhibit_quit are both nil, not just based on Vquit_f= lag=2E >> > >> > It isn't a bug, because emergency exit happens when the count is 2=2E >>=20 >> No, nothing special happens when the count reaches 2=2E > >On TTY frames, it does, doesn't it? > >> These two are mutually exclusive: >>=20 >> The code incrementing force_quit_count is unreachable on text terminals= =2E >>=20 >> The code implementing the Emergency Escape feature is unreachable on GU= I >> terminals=2E > >OK, so once we've established that, what's your point? > >> I note that this triple-C-g behavior is documented only in the code; >> it's missing from trouble=2Etexi=2E > >Yes, but the correct place to document it is in the same section where >the emergency exit is described=2E And talking about inhibit-quit in >the user manual is wrong, because users aren't expected to know about >that=2E And finally, if we want to advertise this, we had better made >it work on all supported platforms=2E > >Last, but not least, this is not directly related to the main part of >this discussion, which is about being able to interrupt Lisp programs >by a single C-g=2E Why is it so important that a *single* C-g interrupt a Lisp program? If a = Lisp program is reading input, and C-g is input, treating at least the firs= t C-g as input is expected, and like I said, it's just not possible to inte= rrupt with a single C-g a program expecting to read input that is also a si= ngle C-g=2E If you try to achieve this goal you either break the input capa= bility or you break the single C-g quit, and you're not addressing this con= tradiction head on=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 10:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498973553749 (code B ref 78737); Sat, 14 Jun 2025 10:36:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 10:35:55 +0000 Received: from localhost ([127.0.0.1]:34854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQOEq-0000xl-1o for submit@debbugs.gnu.org; Sat, 14 Jun 2025 06:35:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56088) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQOEn-0000xB-2i for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 06:35:50 -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 1uQOEg-0004zC-23; Sat, 14 Jun 2025 06:35:42 -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=D0rEfeb9KPCqGzGfSyAQt/+vJfcFbC1FbV+udxX/Il8=; b=bAzoc0pdZWr6 eoBQErc860IyF+F25RliRWKtcFAS3dUyw1oJwCwbKk5Vl/80xmgRyLm62Wj0KZEUCZZ0CyWcALUtL EBR15z/BsqQjCaLY0RqJofeyeldWN4MXzzTB8NjD4dZiVxYlikUx8wWwkkZlX5F+e8XJGX7C5L4sR G9NGeNOCsOlCOn5SHTHucBq1uW8iVBtei1ibYZ9qTlgqg/l07lnt44BJnIWF73945zM9+pEHNZEkp q9ce76FxCuGjRFLiWPVAIZ1fuV2jY8+2gV3wUVcNGWVydOEi/nZOZtOQ8ErMjJntI8UWfCuEdF58Y Pluza0FkZ0AH8BKtUrvCyg==; Date: Sat, 14 Jun 2025 13:35:40 +0300 Message-Id: <86msaasj9f.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <5A8BCAE5-9BD2-401D-897B-FD3A0D8EEBDA@dancol.org> (message from Daniel Colascione on Sat, 14 Jun 2025 06:24:40 -0400) References: <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> <87ikkzwlbu.fsf@protonmail.com> <861prmu728.fsf@gnu.org> <87sek2vjst.fsf@protonmail.com> <86qzzmsny6.fsf@gnu.org> <5A8BCAE5-9BD2-401D-897B-FD3A0D8EEBDA@dancol.org> X-Spam-Score: -2.3 (--) 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: Sat, 14 Jun 2025 06:24:40 -0400 > From: Daniel Colascione > CC: monnier@iro.umontreal.ca, 78737@debbugs.gnu.org > > >Last, but not least, this is not directly related to the main part of > >this discussion, which is about being able to interrupt Lisp programs > >by a single C-g. > > > Why is it so important that a *single* C-g interrupt a Lisp program? Only because it was possible (with some exceptions) until today. Thus, any change in this will be rightfully considered to be an incompatible change in behavior > If a Lisp program is reading input, and C-g is input, treating at least the first C-g as input is expected, and like I said, it's just not possible to interrupt with a single C-g a program expecting to read input that is also a single C-g. If you try to achieve this goal you either break the input capability or you break the single C-g quit, and you're not addressing this contradiction head on. We moved past these arguments, so why go back now? I didn't say we _must_ preserve previous behavior of a single C-g, I just said what is this discussion about. Let's argue where we disagree, not where we don't. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 10:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17498977505917 (code B ref 78737); Sat, 14 Jun 2025 10:43:01 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 10:42:30 +0000 Received: from localhost ([127.0.0.1]:35010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQOLF-0001XM-EK for submit@debbugs.gnu.org; Sat, 14 Jun 2025 06:42:29 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:55900) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQOLC-0001XD-Ri for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 06:42:27 -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=HDPtgtmxB882ZxsnPRBIAZo9s2UZORau1rncPGW2p14=; b=Q6sSC1qwiZl1FOdFUDjRbxrWbS TPhP9UAYfKxE4KAMRR8h0kEHvsixMVSmKt4E/hvh2nXauwQ/o9k9GfK185nSVMh2REaSgXGSSHfHc 8oUGrE6FjH2gztSNmWHKf0G0sr88c662LxIWWFDIxTkIY/DC2Kybec7DgWLWEnz8uilfOfaloM39p FIelL2kNADtWDehSTARgNN/SxiDPjJXiowOZi2paYwBCpnA+gfn6jhf9sdrufkPMQVFgILnR1FmmW c0YMqExODD//oW8enGonzQTs0NhpQxcvbzvjx1Tb86vE57bIHMfvAdmsw4zTeraTTHXKROwdl7+zJ 4fOQ27iQ==; Received: from 2603-9001-4203-1ab2-a30c-ca1e-de1e-2c75.inf6.spectrum.com ([2603:9001:4203:1ab2:a30c:ca1e:de1e:2c75]:48760 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 1uQOJn-00ByrS-0h; Sat, 14 Jun 2025 06:40:59 -0400 Date: Sat, 14 Jun 2025 06:42:20 -0400 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <86zfeasqwe.fsf@gnu.org> References: <8634c7fv4p.fsf@gnu.org> <24893AF1-FB95-4003-81DB-8D4327FD3490@dancol.org> <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <9EF7F59A-8131-4EB5-92B5-D7C805434C59@dancol.org> <86frg3ttxc.fsf@gnu.org> <86zfeasqwe.fsf@gnu.org> Message-ID: <2517288A-6FBB-41A7-9B21-0687213C6EF7@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 14, 2025 3:50:41 AM EDT, Eli Zaretskii wrote: >> Date: Fri, 13 Jun 2025 14:38:22 -0400 >> From: Daniel Colascione >> CC: monnier@iro=2Eumontreal=2Eca, pipcet@protonmail=2Ecom, 78737@debbug= s=2Egnu=2Eorg >>=20 >> On June 13, 2025 1:47:43 PM EDT, Eli Zaretskii wrote: >> >My current understanding is that what you propose will cause some >> >(most) programs to be interruptible with a single C-g, while some (in >> >particular those which call read-event) will need two or more C-g to >> >be interrupted=2E Is that correct? >>=20 >> Yes=2E > >Good=2E > >> However, it looks right now like the class of program that has to be qu= it with a repeated C-g is extremely small=2E I've seen only contrived examp= les so far=2E Most programs do something with the result of calling read-e= vent, and when they see C-g, either break out of their dispatch loop or do = a C-g appropriate thing=2E >>=20 >> Things using low level input events like that, however, tend to be eith= er old or specialized=2E >>=20 >> The most common code paths (e=2Eg=2E isearch, transient, map-y-or-n-p, = etc=2E) with dispatch loops already use higher level tools like read-key, r= ead-char-from-minibuffer, or transient keymaps and so get C-g handled as an= input event anyway=2E >>=20 >> Has anyone complained that (while t (read-key)) doesn't admit keyboard = quitting? >>=20 >> In practice, based on experience so far, there's no practical need to p= ress C-g any more often than one does on mainline=2E >>=20 >> >If this is correct, then we need to decide whether this inconsistency >> >(one C-g vs several) is tolerable=2E >>=20 >> I think it's correct only in theory=2E Maybe I'm wrong and there's some= undiscovered case that this breaks=2E It's to discover these cases that it= would be nice to test the branch and merge it to mainline=2E We can always= put it behind a feature flag=2E > >I don't think we can dismiss use cases just because they are rare=2E Sure: all things being equal, don't break working code=2E=20 >When we get a bug report about some regression, we try to fix the >regression regardless of how frequent the recipe is=2E We do sometimes >decide not to fix such bugs, and in those cases we might bring up >arguments about importance and frequency of the situation=2E But first >we try to fix the bug without considering that=2E > >So if we are going to have a policy of disregarding such regressions >in these cases, we need to see a broad agreement to it=2E > >> >Thanks, but that doesn't answer my question, which is specifically >> >about the effect of C-g on Lisp programs, whether they call read-event >> >or don't call it=2E >>=20 >> Lisp programs that don't call read-event, read-char, or read-char-exclu= sive don't see a change in behavior except for how, once we implement the r= epeated C-g work, users will be able to break out of loops like (while t (r= ead-key)) by pressing C-g multiple times=2E >>=20 >> I have yet to see a real program that does something like this, much le= ss one that depends on bricking quit functionality in the user's Emacs sess= ion=2E >>=20 >> Lisp programs that do call these low level functions see a contract cha= nge, as I detailed in my previous messages=2E > >I understand that Lisp programs which do call those low-level >functions will need to either accept that they cannot be interrupted >by a single C-g, or add some Lisp to quit when they receive a keyboard >input event that's equal to quit-char, is that right? If so, we will >need to clearly identify and document the low-level functions affected >by this=2E The third option is that they handle the C-g they get like any other input= =2E They don't have to necessarily treat it as a quit: for example, a termi= nal emulator might want to forward a C-g to a remote system=2E Documenting new behavior should go without saying=2E The requirement we document, IMHO should revolve around forward progress: = whatever you do with the C-g shouldn't go back to reading a possible C-g in= the same situation=2E Doing that would require the user to break out of yo= ur loop using multiple C-g, which is inconvenient=2E (while (pcase (read-char) (1 (foo) t) (2 (bar) t) (_ (ding) nil))) Fortunately, people tend not to write code like this=2E This guidance applies to higher level input functions like read-key=2E We should also mention in documentation that people should use these highe= r level functions unless they have a specific reason to use the lower level= ones=2E=20 From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 10:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174989850610176 (code B ref 78737); Sat, 14 Jun 2025 10:56:01 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 10:55:06 +0000 Received: from localhost ([127.0.0.1]:35322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQOXR-0002e3-Dv for submit@debbugs.gnu.org; Sat, 14 Jun 2025 06:55:05 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:40698) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQOXN-0002dT-T1 for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 06:55:03 -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=nMlLM3SnJ8iBUTDFOzxhMAN6xArACurgE/2XAMUfLLU=; b=JWrRi7nueiEClm7gAqPKJBFLGJ UnmfFJmIJJiefs6fNhfM+68Kt8YvR7RoUPdeTKS4wV3Nqa4CBW+6Y7JDCyjoaIYLH8hrp3e0HSusN 5RdcIUCOFH4+BdWqooaBttyyH0s2b3cMQjn1k55QTHN7PyRVmgWV16Xf79cLFqRGc0T5jh46JAlJF HoJOl172qApGyv9jBFFoBaPFvFYf9tRbvavLQKOkJB79J+6DKTpePtU9tE7aNDAeU7c/Bd4oF6lTv s++mv4sPzeZv1r1yaCA5U7nTeRi2AzI1KUzl4VNINR74KbGEokly6q0iD/gioNGKZAtiS7AUXJk/K WLadx02w==; Received: from 2603-9001-4203-1ab2-a30c-ca1e-de1e-2c75.inf6.spectrum.com ([2603:9001:4203:1ab2:a30c:ca1e:de1e:2c75]:53386 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 1uQOW0-00Bysk-27; Sat, 14 Jun 2025 06:53:36 -0400 Date: Sat, 14 Jun 2025 06:54:58 -0400 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <864iwiu77s.fsf@gnu.org> References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> <86y0twerm0.fsf@gnu.org> <86jz5ftuk8.fsf@gnu.org> <864iwiu77s.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-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 June 14, 2025 3:12:55 AM EDT, Eli Zaretskii wrote: >> From: Stefan Monnier >> Cc: dancol@dancol=2Eorg, 78737@debbugs=2Egnu=2Eorg, pipcet@protonmail= =2Ecom >> Date: Fri, 13 Jun 2025 14:14:44 -0400 >>=20 >> >> > (while t >> >> > (let (evt (read-event)) >> >> > (do-something-with evt))) >> >> > >> >> > _can_ be interrupted? >> >>=20 >> >> Usually the `(do-something-with evt)` part will offer some way to en= d >> >> the loop=2E >> > >> > How? If read-event returns the character 7, then the information >> > about the fact that C-g was typed is lost by the time we get to the >> > do-something-with part, no? >>=20 >> AFAIK that information is in `evt` and hence not lost=2E > >That's not what I see on the branch=2E read-event returns the character >7, a scalar=2E Or am I missing something? That's the encoding of C-g=2E What information is lost? >> Usually `do-something-with` will look at `evt` and do various things >> depending on the key that was pressed and usually one of those options >> lets you end what you were doing=2E >>=20 >> Some code may assume they don't need to explicitly abort when `evt` is >> 7 because they rely on the current behavior of `read-event`, but AFAIK >> that behavior is not completely reliable (e=2Eg=2E it depends on >> `inhibit-quit` and sometimes timing), so if we want to encourage use of >> that feature we should try and make it more reliable=2E > >So you are saying that, to be interruptible by a single C-g, a Lisp >program that calls read-event will need to have code that quits under >certain circumstances when read-event returns 7, is that right? >Doesn't that mean we will now require every program that calls >read-event to have such Lisp code, where it previously didn't? I've seen that in practice are interruptable in this manner already=2E It = looks like use of higher level functions like read-key or transient maps is= already more common in higher level code and that this code already reacts= properly to receiving C-g as input=2E I do see a bit of variety in what programs actually do when they get C-g t= hough=2E Some signal quit=2E Some call keyboard-quit, which is harmless bec= ause it eventually signals quit, but is less clear and does unnecessary wor= k before signaling quit=2E It'd be nice to guide high-level and low-level input readers alike to quit= by signaling quit rather than trying to call keyboard-quit and such themse= lves=2E >Pushing quitting to the application level is not something that will >be appreciated by Lisp programmers, I think=2E We've been pushing quitting to applications for decades when these applica= tions use the higher level input reading functions=2E Check out how we do i= t in, e=2Eg=2E calc=2E I haven't seen any objections=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 11:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet , Lynn Winebarger Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174989948915911 (code B ref 78737); Sat, 14 Jun 2025 11:12:02 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 11:11:29 +0000 Received: from localhost ([127.0.0.1]:35698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQOnF-00048V-MY for submit@debbugs.gnu.org; Sat, 14 Jun 2025 07:11:29 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:39648) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQOnC-00048L-TD for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 07:11:24 -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=DhklzdPW/F6Ys8b7vw4qIiydeb5SbgvkCGxNrQ5hVXE=; b=N9sb5UUGoZ7AtP9umMI47Yj/37 JnBj2Se/UMXCSJsJpNtcfCeGcUOiMUyVKg+6wwOnxK0K6mhpSDM0ZaKDUl8sEV+h/Vj6oCID+LMPx QMSY2b2aXcqH3hHHtk3BYmmLqBk0EuMXdFvsOFaazyFz0i+9toGVUe25DJj5diBIHr7fMUiO2/Oov uyhxXLdAG6buP7QW6GYwWvp61VfN4dz53PlYrYHibErY3/j50BsEg0fJHKEHWpdkS4jNm/rpx8vwD 7TwtV8To0n/GY4pJBpWy1GgV2Wru845paL0D62v7Mcej0DgcyMVZr9VUfTZ1+6TwHfw3f74eiD9fA aEvrekYg==; Received: from 2603-9001-4203-1ab2-a30c-ca1e-de1e-2c75.inf6.spectrum.com ([2603:9001:4203:1ab2:a30c:ca1e:de1e:2c75]:58734 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 1uQOll-00Byvu-1Z; Sat, 14 Jun 2025 07:09:53 -0400 Date: Sat, 14 Jun 2025 07:11:14 -0400 From: Daniel Colascione User-Agent: K-9 Mail for Android In-Reply-To: <874iwix2fk.fsf@protonmail.com> References: <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> <37BCCFA8-8EFC-4BB1-8B4F-D805FB7E1B6A@dancol.org> <874iwix2fk.fsf@protonmail.com> Message-ID: <56759942-A17A-4B19-9EB6-DB5EF63C48E2@dancol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) 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 June 14, 2025 2:28:06 AM EDT, Pip Cet wrote: >"Lynn Winebarger" writes: > >> On Fri, Jun 13, 2025 at 10:02=E2=80=AFAM Daniel Colascione wrote: >>> >>> >>> >>> On June 13, 2025 6:42:58 AM PDT, Daniel Colascione wrote: >>> > >>> > >>> >On June 13, 2025 5:23:34 AM PDT, Lynn Winebarger wrote: >>> >>On Fri, Jun 13, 2025, 2:26=E2=80=AFAM Eli Zaretskii = wrote: >>> >> >>> >>> > From: Daniel Colascione >>> >>> > Cc: Eli Zaretskii , monnier@iro=2Eumontreal=2Ec= a, >>> >>> > 78737@debbugs=2Egnu=2Eorg >>> >>> > Date: Thu, 12 Jun 2025 11:48:50 -0700 >>> >>> > >>> >>> > Pip Cet writes: >>> >>> > >>> >>> > > I'd like read-event, when called while inhibit-quit is t, to r= eport >>> >>> > > quits by setting quit-flag in addition to returning quit_char:= it'll >>> >>> > > simplify the C code, and it would make >>> >>> > > >>> >>> > > (while t >>> >>> > > (let ((inhibit-quit t)) >>> >>> > > (read-event))) >>> >>> > >>> >>> > I strongly disagree=2E read-event should read an event=2E >>> >>> > Setting quit-flag by side effect when it happens to read one key= and not >>> >>> > others makes the interface less regular and understandable=2E >>> >>> >>> >>> We should start by agreeing that the capability of interrupting a >>> >>> running Lisp program is a real need=2E Are we in agreement about = that? >>> >>> If not, let's first hear the arguments why not=2E >>> >>> >>> >>> If we _are_ in agreement about that, we should discuss how this sh= ould >>> >>> be possible if read-event (and perhaps others?) return C-g instead= of >>> >>> raising quit-flag=2E The alternatives mentioned until now are: >>> >>> >>> >>> =2E restore the old behavior, whereby C-g interrupts read-event >>> >>> =2E have a variable that, if set, will restore the old behavior i= n >>> >>> read-event and other affected primitives, to be interruptible b= y a >>> >>> single C-g >>> >>> =2E make two C-g presses "in quick succession" set quit-flag, IOW >>> >>> "C-g C-g" will have the same effect as C-g previously >>> >>> >>> >>> Are there other alternatives? >>> >>> >>> >> >>> >>What about keeping a (possibly buffer-local?) lisp variable holding = a list >>> >>of keystrokes mapped to thunks that are treated as generating lisp m= achine >>> >>"interrupts"? The key strokes would be processed by C machinery and= never >>> >>seen directly by lisp code and not be considered "events"=2E >>> >>Then C-g could be bound to a thunk signalling quit, and the effect o= f >>> >>"inhibit-quit" achieved by removing C-g from the list in a given dyn= amic >>> >>scope=2E Then user code could make other key-strokes "special" with= out >>> >>resorting to read-event=2E For example, this read-event call in ter= m=2Eel: >>> >>(message "Hit space to flush") >>> >> (let ((ch (read-event))) >>> >> (if (eq ch ?\s) >>> >> (set-window-configuration conf) >>> >> (push ch unread-command-events))) >>> >> >>> >>Could be replaced by something like >>> >>(with-interrupts ((?\s (signal term-flush))) >>> >> (condition-case nil >>> >> (while t (sit-for 100)) >>> >> (term-flush (set-window-configuration conf)))) >>> >> >>> >>Then some of these use-case concerns could be mooted altogether=2E >>> > >>> >We already have something like that=2E :-) read-event already runs >>> > the events it reads through special-event-map, right? We don't >>> > even need to create a separate thunk list concept: we could just >>> > bind C-g in special event map and do what we want, right? > >> Would that provide the behavior Pip is looking for? > >It would not, because quits are currently processed out-of-order, and >this important feature should remain in place for "serious" quits=2E See >below=2E Not out of the box, true=2E In principle, though, it would be possible to = scan special-event-map for single-key bindings and treat them all like we d= o quit_char for purposes of Lisp interruption, input discarding, and so on= =2E For example, while I'm debugging something, it'd actually be nice to have = a single key to instantly invoke the debugger without having to deal with t= he inconvenience of debug-on-quit breaking into the debugger in a lot of pl= aces I would rather it not=2E Likewise, it'd be convenient to have the ability to bind a key at a low le= vel to something that would instantly launch and attach GDB without having = to deal with the friction of creating a terminal, finding the Emacs PID, st= arting the debugger, and attaching by hand=2E Not the most important thing to do right now, but there do seem to be actu= al use cases for binding behaviors to keys in the manner we do for quits=2E From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 11:13:04 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, monnier@iro.umontreal.ca Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174989952716145 (code B ref 78737); Sat, 14 Jun 2025 11:13:04 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 11:12:07 +0000 Received: from localhost ([127.0.0.1]:35722 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQOnu-0004CL-Og for submit@debbugs.gnu.org; Sat, 14 Jun 2025 07:12:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57062) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQOnr-0004BU-Mb for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 07:12:04 -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 1uQOnl-0001El-Oz; Sat, 14 Jun 2025 07:11:57 -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=6909TLfiTAyw+UvW5ena3N7+NxKPnEonNAVQlgkfLJE=; b=kULfLsAbf6la k/YhcJrV1f61v91DGm08eioR9r/yPTvCPz1PyCbheGTqdYzjMj7K/JZu8VnbxcHSb4xLDc0MZcoau y83tOpxjvp5ufqQdQiDK3eGcvR/fGYFNTf+EfmS0nOWgSOGcpkYuSuvxiKeqZHcfR+S+kKeN9i98N pPljhKipP/DFVCDNx85cqn7wwU40KMhiceBip2I3N35tEU4vQHTaT4rtdP9OZZU3ZM2vI9Frm7J0a z6uvTZcZa/r8eHMaQgOmkCnx/EqlI22aT+QvX8R7DTjjlf5WeIKt0gyT9oSl7P6o7B0NbgjaBc2zp H0xPAqGVpCinVmTE5mkqsQ==; Date: Sat, 14 Jun 2025 14:11:56 +0300 Message-Id: <86jz5eshkz.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Colascione on Sat, 14 Jun 2025 06:54:58 -0400) References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> <86y0twerm0.fsf@gnu.org> <86jz5ftuk8.fsf@gnu.org> <864iwiu77s.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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: Sat, 14 Jun 2025 06:54:58 -0400 > From: Daniel Colascione > CC: 78737@debbugs.gnu.org, pipcet@protonmail.com > > >Pushing quitting to the application level is not something that will > >be appreciated by Lisp programmers, I think. > > We've been pushing quitting to applications for decades when these applications use the higher level input reading functions. Check out how we do it in, e.g. calc. I haven't seen any objections. I know, but these arguments don't work when applications that didn't do that in the past are suddenly required to do it. What Calc does is intentional, so why would we expect any objections in those cases? Objections will come when code which didn't need to do this will be required to do so. From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Lynn Winebarger Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jun 2025 17:38:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione , Stefan Monnier Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174992264726075 (code B ref 78737); Sat, 14 Jun 2025 17:38:03 +0000 Received: (at 78737) by debbugs.gnu.org; 14 Jun 2025 17:37:27 +0000 Received: from localhost ([127.0.0.1]:42557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQUon-0006mN-Nj for submit@debbugs.gnu.org; Sat, 14 Jun 2025 13:37:26 -0400 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:39199) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1uQUof-0006kH-25 for 78737@debbugs.gnu.org; Sat, 14 Jun 2025 13:37:23 -0400 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-3a528e301b0so392590f8f.1 for <78737@debbugs.gnu.org>; Sat, 14 Jun 2025 10:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749922631; x=1750527431; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=DYKeVAfZX35HssixeRo2kNaBY64+8WTPF1jOpzhk5rM=; b=huYwF9egXqYUHwV8rdCw3d3ENxDS/1ezFFr1CpA9n5Li/+PHn/Q1+jMgzxwEgvbmbH eGQP/G9F6SYuRCz4Z6kLsV4ynAXC/yMPzKG6sQ4TNkCIx/H3pg6mKGwRexCx3uEhLCWQ fL52dj8Tt6FWYQKJrcOTb1CzFrrOKDsOtW2WheXu7/LAzU3RtUo4/frRrRVzC+GjdRfV KUEv8HG264NC9nc1yUNJl+y9NEj4Zee2sFyWIjbE4NId3bNVAIgqUoSmtETrrCZYDm4l GeAoGIhwEbupNEvDzOhErhUqOK4Aj8dkZ3ygEq4d0DM7klNt7tzUXcztO95v/3HoyKHJ bgkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749922631; x=1750527431; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DYKeVAfZX35HssixeRo2kNaBY64+8WTPF1jOpzhk5rM=; b=db2q2nE4Jw6VuiKONmDx5vnew83XAXyJNwavDkRsvIg0ushU1X2DEaqn+XBun3/L75 JXrjJZyawG6iBaAuar1/V3qED08X3j2Eg9Y7Vi3aFEcpCZaMh0DOap4yemaw1RSbR2xc bCwg7wsck3VK2ciHFO0Gz3g351hx6SbcUusbhYq5Fr0zFYPWNEEnDQYicsFwNc2S5LG8 HK/IGB1sLPYzAjcMnCP7EJp38FCfUM6hW1tqjxaW80g3qalHmbmXL4COx9I0J1eQg7lQ 6i6r5uzS8qpFcQLI4ZlUMz4PMw8XuaA7GSWzqZqtALNvnkPODZOtqccp+hpygQ+DaTiH dODA== X-Forwarded-Encrypted: i=1; AJvYcCVmqLq7FC955EDes1fzgX9dG6Qzy5CSsEcly8/6gcAbNrqdWfoH5GrdGpkcf0S/2KbcLenVbQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxF3wH8V137iz1fEkp1mn1ij8FUJ9Fc6I/1p6aNhYn7lIjM0gER EpBZCTp6LNWQiR/0xo6/sMpsuKxxvF+ckqDJSPgo+pY2njrlhFmUK6s/eA0SA/KOXTtCfc+DGkW Me7wvxXCIYlxeFviN2v7AXjK6Ay0zHIg= X-Gm-Gg: ASbGncviAuyQXOJajsr5PaRChIHurr9mAYXLQTQ6vJfl0cpxXkENusI82IGMmBhZJZC IdzI752CHk2dB024/A2aKlVk2aE9au6FqnPde2cYIhSas045aiomZ7rhDe1uofb5HiQIyrtu+M4 ivujzJ2/lhIUVcaKTJ1GI2B+8LRMpAI1MEkq6b6nn4BjvVt54hhnOu8uKx9JlGVRVDCRcPV+b38 WE= X-Google-Smtp-Source: AGHT+IFKt8lNkmLdPfRhC2XFOHxwJRiKKCOg8tdUQy50jObJnWi5WaSVtF6hrVUFflfQeKreyrwr41o9dyl/TMdUsN4= X-Received: by 2002:a05:6000:40cb:b0:3a5:78f6:c7c1 with SMTP id ffacd0b85a97d-3a578f6d4f8mr461961f8f.1.1749922630541; Sat, 14 Jun 2025 10:37:10 -0700 (PDT) MIME-Version: 1.0 References: <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> <37BCCFA8-8EFC-4BB1-8B4F-D805FB7E1B6A@dancol.org> <874iwix2fk.fsf@protonmail.com> In-Reply-To: <874iwix2fk.fsf@protonmail.com> From: Lynn Winebarger Date: Sat, 14 Jun 2025 13:36:59 -0400 X-Gm-Features: AX0GCFu4jayBcan0lhz1U_YD_OQTyJwByWEKeuKXLxkHjYOx8wqH2vVVAVd5Yes Message-ID: Content-Type: multipart/alternative; boundary="000000000000c72b7f06378b9c98" X-Spam-Score: 0.0 (/) 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 (-) --000000000000c72b7f06378b9c98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Jun 14, 2025, 2:28=E2=80=AFAM Pip Cet wrote= : > "Lynn Winebarger" writes: > > > On Fri, Jun 13, 2025 at 10:02=E2=80=AFAM Daniel Colascione > wrote: > >> > >> > >> > >> On June 13, 2025 6:42:58 AM PDT, Daniel Colascione > wrote: > >> > > >> >We already have something like that. :-) read-event already runs > >> > the events it reads through special-event-map, right? We don't > >> > even need to create a separate thunk list concept: we could just > >> > bind C-g in special event map and do what we want, right? > > > Would that provide the behavior Pip is looking for? > > It would not, because quits are currently processed out-of-order, and > this important feature should remain in place for "serious" quits. See > below. > > >> >The only special thing about C-g is how we treat it when Lisp is > >> > running. When it's instead reading an event, it can and be a > >> > boring event processed the same way every other event is. > > > It seems to me what Pip is looking for is analogous to a "Quit" button > > hardwired to a pin on a CPU, which is not something that can be > > reliably implemented in the C primitives as they are now. > > You're suggesting I'm looking for something that cannot be implemented. > I'm not. > That was not my intention. I don't think that hard-wired behavior can be reliably implemented one read_char has started processing an input event off its queue. There's just too many ways a keystroke can get consumed or discarded that may not even be in the C primitives, as far as I can tell. At least, that's what it looks like from a cursory reading of read_char. It seems to me the most reliable way to guarantee C-g or any other designated special input is treated specially is to make sure they don't enter the queue processed by read_char at all. And the most reliable way to do that is probably to make the signal handler indicating keystrokes are available, split the special keystrokes off into their own queue right from the start. How much actual processing might be done from the handler's activation frame is a separate matter. For example, the signal handler could increment a quit count if it isn't already, then do something more aggressive if the count exceeds some threshold, like throwing directly from the signal handler rather than waiting for the C code to reach some point safe for throwing. > > I described specific situations in which I think quit should be expanded > to work better than it does now. No one's expecting that quit works in > absolutely every situation, as far as I know. That's what gdb is for. > Actually, I'd love C-g to reliably interrupt Emacs when it appears locked up and I have no idea why. It's probably annoying to other users who don't have a copy of Emacs built for debugging to not be able to kick Emacs out of an infinite loop (or worse) as well. > If you're referring to the "C-g C-g" thing, I did not describe how I'd > implement it in detail, because there are many choices to be made; but > the main idea would be that we should not immediately clear inhibit-quit > for that combination, because that's a dangerous and destructive thing > to do. If we decide to do so (after a delay, for example), we need to > print a clear warning to the user that their Emacs session needs > restarting. > > So C-g C-g might do less than GUI C-g C-g C-g does currently. > > There are actions even more dangerous than clearing inhibit-quit. I > don't know whether we want a level-3 quit which does even more than the > current GUI C-g C-g C-g code. > I don't really understand the necessity or use of inhibit-quit, as opposed to, say, pushing a new quit handler or blocking input altogether, if the consistency of the lisp machine state is a concern (e.g. to prevent throwing from a signal handler). Lynn --000000000000c72b7f06378b9c98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Jun 14, 2025, 2:28=E2=80=AFAM Pi= p Cet <pipcet@protonmail.com> wrote:
&qu= ot;Lynn Winebarger" <owinebar@gmail.com> writes:

> On Fri, Jun 13, 2025 at 10:02=E2=80=AFAM Daniel Colascione <dancol@d= ancol.org> wrote:
>>
>>
>>
>> On June 13, 2025 6:42:58 AM PDT, Daniel Colascione <dancol@danco= l.org> wrote:
>> >
>> >We already have something like that. :-) read-event already ru= ns
>> > the events it reads through special-event-map, right? We don&= #39;t
>> > even need to create a separate thunk list concept: we could j= ust
>> > bind C-g in special event map and do what we want, right?

> Would that provide the behavior Pip is looking for?

It would not, because quits are currently processed out-of-order, and
this important feature should remain in place for "serious" quits= .=C2=A0 See
below.

>> >The only special thing about C-g is how we treat it when Lisp = is
>> > running. When it's instead reading an event, it can and b= e a
>> > boring event processed the same way every other event is.

> It seems to me what Pip is looking for is analogous to a "Quit&qu= ot; button
> hardwired to a pin on a CPU, which is not something that can be
> reliably implemented in the C primitives as they are now.

You're suggesting I'm looking for something that cannot be implemen= ted.
I'm not.

That was not my intention.=C2=A0 I don't think that hard-wired beha= vior can be reliably implemented one read_char has started processing an in= put event off its queue.=C2=A0 There's just too many ways a keystroke c= an get consumed or discarded that may not even be in the C primitives, as f= ar as I can tell.=C2=A0 At least, that's what it looks like from a curs= ory reading of read_char.=C2=A0=C2=A0
It seems to me= the most reliable way to guarantee C-g or any other designated special inp= ut is treated specially is to make sure they don't enter the queue proc= essed by read_char at all.=C2=A0 And the most reliable way to do that is pr= obably to make the signal handler indicating keystrokes are available, spli= t the special keystrokes off into their own queue right from the start.=C2= =A0 How much actual processing might be done from the handler's activat= ion frame is a separate matter.=C2=A0 For example, the signal handler could= increment a quit count if it isn't already, then do something more agg= ressive if the count exceeds some threshold, like throwing directly from th= e signal handler rather than waiting for the C code to reach some point saf= e for throwing.

I described specific situations in which I think quit should be expanded to work better than it does now.=C2=A0 No one's expecting that quit wor= ks in
absolutely every situation, as far as I know.=C2=A0 That's what gdb is = for.

Actually, I'd love C-g to reliably interrupt Emacs when it appears = locked up and I have no idea why.=C2=A0 It's probably annoying to other= users who don't have a copy of Emacs built for debugging to not be abl= e to kick Emacs out of an infinite loop (or worse) as well.



If you're referring to the "C-g C-g" thing, I did not describ= e how I'd
implement it in detail, because there are many choices to be made; but
the main idea would be that we should not immediately clear inhibit-quit for that combination, because that's a dangerous and destructive thing<= br> to do.=C2=A0 If we decide to do so (after a delay, for example), we need to=
print a clear warning to the user that their Emacs session needs
restarting.

So C-g C-g might do less than GUI C-g C-g C-g does currently.

There are actions even more dangerous than clearing inhibit-quit.=C2=A0 I don't know whether we want a level-3 quit which does even more than the=
current GUI C-g C-g C-g code.

I don't really understand the necessity or= use of inhibit-quit, as opposed to, say, pushing a new quit handler or blo= cking input altogether, if the consistency of the lisp machine state is a c= oncern (e.g. to prevent throwing from a signal handler).

Lynn

--000000000000c72b7f06378b9c98-- From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 06:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174996950913716 (code B ref 78737); Sun, 15 Jun 2025 06:39:02 +0000 Received: (at 78737) by debbugs.gnu.org; 15 Jun 2025 06:38:29 +0000 Received: from localhost ([127.0.0.1]:52747 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQh0e-0003Z7-Jy for submit@debbugs.gnu.org; Sun, 15 Jun 2025 02:38:29 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3532) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQh0c-0003Yb-DV for 78737@debbugs.gnu.org; Sun, 15 Jun 2025 02:38:26 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5107F1000BC; Sun, 15 Jun 2025 02:38:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749969499; bh=O7BxURFp/pYBphBFhCHwOPQulEqz4Li/PpydYy8Rz6E=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=bUEBTV9KCaTiYgavv1hSDz6NvIX6XivvUlIUhjapqxMjmTiUkOzcmu+WjC54kBI8o osMcW/4DVNovszhx1R/VWECSvT1q3++3tIESnOqMlhowjklW4q8ilZEYwPA/F8gtYV gfNhV8YLkMM8YkKxZor2I+L/CvZFWiGRdL3oKRa5v5cGj+pPtDr5q9P/NS7q+Nf6DU qEnDje25MQGX5VF2FtQf4p+HfYFA6f14AF1gDIH+TUaSzwcc4VVBrzYf+EwMRaJPc7 OVJlKvar88LGeYcJkfEGMrYOqZdHcfdlXMjV46WUI8GN5sdLAnjVQYhwHGXCZEs3za urxAkK/O2rtsA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 66537100029; Sun, 15 Jun 2025 02:38:19 -0400 (EDT) Received: from asado (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E029B120506; Sun, 15 Jun 2025 02:38:17 -0400 (EDT) From: Stefan Monnier In-Reply-To: <8634c2u76g.fsf@gnu.org> Message-ID: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> <8634c2u76g.fsf@gnu.org> Date: Sun, 15 Jun 2025 02:38:14 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.079 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> >> What is "emergency quit"? >> > Something like `C-g C-g C-g`, tho we don't have that implemented, >> > currently, AFAIK. >> I guess `kill -USR2` could count as well. > Not as a single trigger, no: it isn't portable enough. It's still a valid example of what I mean by "emergency quit": a mechanism by which users can get out of (hopefully rare) "hangs" that are due to ELisp coding mistakes. But yes, it's not "good enough", so we want to offer another mechanism such as `C-g C-g C-g`. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 06:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.174997007016909 (code B ref 78737); Sun, 15 Jun 2025 06:48:02 +0000 Received: (at 78737) by debbugs.gnu.org; 15 Jun 2025 06:47:50 +0000 Received: from localhost ([127.0.0.1]:52822 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQh9i-0004Oe-GX for submit@debbugs.gnu.org; Sun, 15 Jun 2025 02:47:50 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18011) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQh9g-0004O7-Lq for 78737@debbugs.gnu.org; Sun, 15 Jun 2025 02:47:49 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 39D58801B6; Sun, 15 Jun 2025 02:47:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1749970058; bh=jA0u7NtFPnlKgghLZ/9/XGbSiX2ZERS9QRrzup1znM0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=iQjk/fTSs5ZybgFE+KG9ckQYIjwME5P+H0zQTTEFb7ECiYQUXZ0dpTxtEa/bjRWgY Mmkk42LfbJh6QXybI/YOrXjQkymb7dYckkqnrsLccWzlAQki/WByFEwMr0VXeq5ogU r9/PmF9Tdu84vaNlZbSrzCa+XosYeWWiDUUGGUMGMrLb6W1Bq7tLMDQCPP3cenPqzq NkV5wHdpc5u2uJ5b6kRl1qGaN0NJortWBmrYGhgR1gzB5Q3VbqXwUAuNMg9wjRIUBv svA41BWiwOo5boIDKlZl1bFFb6vwtxtCW1ERyQcZ1vob73K7M8S5JQRBuv5/WNwUOl lwovpruQwWudg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 4BDC1808F6; Sun, 15 Jun 2025 02:47:38 -0400 (EDT) Received: from asado (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 57B371201DA; Sun, 15 Jun 2025 02:47:37 -0400 (EDT) From: Stefan Monnier In-Reply-To: Message-ID: References: <87msaf1omo.fsf@protonmail.com> <6DD09442-EDD3-411F-8F90-5145612AE177@dancol.org> <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> <86y0twerm0.fsf@gnu.org> <86jz5ftuk8.fsf@gnu.org> Date: Sun, 15 Jun 2025 02:47:34 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.158 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > We should steer developers away from read-char and towards higher level > features like read-key anyway, right? +1 Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 17:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Colascione Cc: 78737@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.175000995223676 (code B ref 78737); Sun, 15 Jun 2025 17:53:02 +0000 Received: (at 78737) by debbugs.gnu.org; 15 Jun 2025 17:52:32 +0000 Received: from localhost ([127.0.0.1]:60100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQrWx-00069o-Tb for submit@debbugs.gnu.org; Sun, 15 Jun 2025 13:52:32 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:28540) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQrWv-00069G-M6 for 78737@debbugs.gnu.org; Sun, 15 Jun 2025 13:52:30 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 278581000BC; Sun, 15 Jun 2025 13:52:23 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1750009941; bh=XZyhrEdzkaV04S6irziYqJ0OFmbTB9vvTzAxp2dImOI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Ez4S+H7KTOzyiu14JP7Kzvqo1csIBf3/4I5gt13kphA7W+Vd0oxTvgaeEackMLj1R rcU3WXw4fJlxIzZmFVjPzK3khqyqegsbPN1yoS78jSvMPJ7fPBpbeg0xyBJB6yGro4 SKTrn89NFxQ/hHSv7/SLPhFlfHRWqL3qY1uDwjdWCdMojihKBz+muJhyXA/mouyCF8 YPgiEZtBn8yX3kkoAHUG0hH5HRi/DtVWrgJsZxzeRaKXVtXPjxKQsVxZV+KuyQDDVT xfwpak3ZyObgyPVYvDX0AK+iL2D5RMNKPGyBfOHKsqIbT4ZVI498K2JyWagmq7Ol6/ 8NLLECKdWniJw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BF3B310002E; Sun, 15 Jun 2025 13:52:21 -0400 (EDT) Received: from asado (unknown [104.129.158.226]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 934B51200B0; Sun, 15 Jun 2025 13:52:21 -0400 (EDT) From: Stefan Monnier In-Reply-To: <4BCDF146-4265-4070-9223-E6A6902F6BC9@dancol.org> Message-ID: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <86ikkztudd.fsf@gnu.org> <4BCDF146-4265-4070-9223-E6A6902F6BC9@dancol.org> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sun, 15 Jun 2025 13:52:16 -0400 MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > C-g C-g C-g --- urgent quit (breaks out of read-event. should probably > break out of redisplay too?) Side note: "breaking out of redisplay" is not straightforward for various reasons, such as the fact that most places where we run ELisp try and catch every non-local exit (tho we fail to catch some `throw`s, IIRC), or the fact that non-local exits may leave some redisplay data-structures in an inconsistent state, or the fact that even if we sucessfully interrupt a redisplay hang, we're likely to fall right back into it at the next redisplay (hence really soon). > C-g C-g C-g C-g C-g C-g --- emergency quit. ignores inhibit-quit. good > chance of horking your Emacs by violating atomicity assumptions. Sometimes a single `C-g` is sufficient, but it can still take a short while for Emacs to reply, so the user may hit `C-g` repeatedly without necessarily meaning to break a "hard hang", so it would be nice to have some way to distinguish the two. > Display "are you sure?" message before final C-g. That's indeed one way to distinguish the two, but of course, maybe displaying that message could get us back into the hang. Another (similar option) is to jump into the debugger (from where the users can "continue" or jump to toplevel, but which can also fall back into the hang the user is trying to get out of). Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 17:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org, owinebar@gmail.com Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.175001025425529 (code B ref 78737); Sun, 15 Jun 2025 17:58:02 +0000 Received: (at 78737) by debbugs.gnu.org; 15 Jun 2025 17:57:34 +0000 Received: from localhost ([127.0.0.1]:60193 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQrbq-0006de-9i for submit@debbugs.gnu.org; Sun, 15 Jun 2025 13:57:34 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:55719) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQrbo-0006dA-5H for 78737@debbugs.gnu.org; Sun, 15 Jun 2025 13:57:32 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 869D44407A0; Sun, 15 Jun 2025 13:57:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1750010241; bh=6MthXMdIhqk9gN4m9LBUuNObp9trKvjAB86+Ngb0U1c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=e3bZNUz1b4wJAHY6KZT1ptN4wdZaDiCGL90TM1NHKssTXHigr1M6g1HjIxcu3N0eR GqDJW8PlC9mEeEJGD5IoHXfa14Tdaju98Slp2r+wfRAGEwRivUlAMf3WtFbj+wv3Nw RUwe5gn7jZOZL1q+14NawfyxkEpHi4caKqnMkecyVESO2utzp8e382Ghuf8XcXENqz OUIky4bFREQWkwgvLwn+g5o1f8/xsLD77R9Ds9iavcGayDF0sExqOMTyFlN4wq011p FQLDVlDjqevAVi6XcyLz7bXIj/IjMx2t8Fmdtu2HhY9tSZWyeOyvDh07Y5jMHH5hXB DTPUtVZ1SuT7g== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 68EF144079B; Sun, 15 Jun 2025 13:57:21 -0400 (EDT) Received: from asado (unknown [104.129.158.226]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0364612062E; Sun, 15 Jun 2025 13:57:20 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86tt4isptf.fsf@gnu.org> Message-ID: References: <87h60m1sdg.fsf@protonmail.com> <86frg6e6uj.fsf@gnu.org> <86v7p2gxlv.fsf@gnu.org> <87sek5ysbs.fsf@protonmail.com> <86bjqsgbtx.fsf@gnu.org> <875xh0ztz2.fsf@protonmail.com> <86sek4duov.fsf@gnu.org> <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@dancol.org> <86tt4isptf.fsf@gnu.org> Date: Sun, 15 Jun 2025 13:57:11 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) >> I'd deprecate read-event TBH. When I introduced `read-key` the intention was for it to make `read-event` mostly obsolete, but the replacement is a slow process because of ... details. > If we want to do this, we should start by removing it from our own > sources. Currently, we use it in around 80 places. +1 Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 18:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.175001061427635 (code B ref 78737); Sun, 15 Jun 2025 18:04:01 +0000 Received: (at 78737) by debbugs.gnu.org; 15 Jun 2025 18:03:34 +0000 Received: from localhost ([127.0.0.1]:60265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQrhe-0007Be-El for submit@debbugs.gnu.org; Sun, 15 Jun 2025 14:03:34 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25527) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQrhc-0007B3-RV for 78737@debbugs.gnu.org; Sun, 15 Jun 2025 14:03:33 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 49CD844095F; Sun, 15 Jun 2025 14:03:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1750010606; bh=r40UfgYddoBEDHItYCrUxZILag3eS5eR4T4n5kMB/gI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NHyXkSw5iuWC47t/hxLXblOFyySdAZ06o2wtr29LecMeS0RcfZ6p73VEu02WSLWf+ KeAXBMpsKKtPDBIzkm4J986OqFlEFECMxsk0t8z75eP5hai7ei1c4tHz6BJh/aRZaZ XL9Sd1hG6N5hDFfjwxGm/W1EHHWTpo0D3JI5F58Dk431WaOpky6sc7faWsWJvbucqP 43MLqlWPvs3TUa/BQyLxq8qOPQtInEE8KHoiNjlWchDwCR1KeBtvefaBe6/okH+Rim rajwvpZbHDhJs+lwiyX/T7uvJ/c2Lyb8hnfZV51sdveoHgGgPZBGPW0OF7bOZlwGJf /84tK8jyRhRCw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3F36A44079B; Sun, 15 Jun 2025 14:03:26 -0400 (EDT) Received: from asado (unknown [104.129.158.226]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C0F7A120403; Sun, 15 Jun 2025 14:03:25 -0400 (EDT) From: Stefan Monnier In-Reply-To: <86plf6sn4s.fsf@gnu.org> Message-ID: References: <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <868qluu9ev.fsf@gnu.org> <87y0tuvn15.fsf@protonmail.com> <86sek2sp20.fsf@gnu.org> <86plf6sn4s.fsf@gnu.org> Date: Sun, 15 Jun 2025 14:03:16 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) 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 (---) > It seems this feature was originally known as "immediate quit". > At some point the immediate_quit variable itself was removed, but the > term seems appropriate regardless. So I suggest that's how we > call it. Hmm... I thought the `immediate_quit` variable was used for yet another notion of "immediate quit". Maybe I'm confused. Stefan From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 18:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, Eli Zaretskii , Daniel Colascione Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.175001080628890 (code B ref 78737); Sun, 15 Jun 2025 18:07:02 +0000 Received: (at 78737) by debbugs.gnu.org; 15 Jun 2025 18:06:46 +0000 Received: from localhost ([127.0.0.1]:60312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQrkk-0007Vu-98 for submit@debbugs.gnu.org; Sun, 15 Jun 2025 14:06:46 -0400 Received: from mail-10630.protonmail.ch ([79.135.106.30]:14847) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQrkh-0007VR-TE for 78737@debbugs.gnu.org; Sun, 15 Jun 2025 14:06:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1750010796; x=1750269996; bh=3ynEmjKeT92//3lFTQ7AWFfMSMp+8LWwAqNZR0BVco0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=hkm9nvm8BWtFNep9YJrLHuOU8QDNKpmE/vSIKQR41x3bSxqCTRy3Xj3dbBIZNzWDJ mcHIJAeVWWaLYz8y6O6AuiO8HyjyPJ5C2lUlDaKDS1paGWXET8pNG7B7GyrJFeRtmx hxuHs2c24oUTXWoAwnWfPu/YdxOTv3+Hxt565qefIsIAvLqQlYSKD71naQw0ApCccW 4U1QEPU/c5P1qObmHWSN48ZgFxaFzguWV77/xK0LmATYLn68Z02K1Uo/fCsdvWygHG tzff0sjsEPfYC/MJIBRo+4pw5OfBsbrl+DBEYaKnMZ3jO+mSuoMkq/1Za11dG81247 lfIlgYrokG4ug== Date: Sun, 15 Jun 2025 18:06:32 +0000 From: Pip Cet Message-ID: <875xgwvpzy.fsf@protonmail.com> In-Reply-To: References: <865xh0gapx.fsf@gnu.org> <79889093-562A-45E6-ACF2-72662956F3CA@dancol.org> <86y0twerm0.fsf@gnu.org> <86jz5ftuk8.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b276321abe9ceb827f1e765d4fa19053cfd5795d MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) 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 (-) "Stefan Monnier" writes: >> We should steer developers away from read-char and towards higher level >> features like read-key anyway, right? > > +1 I agree in principle, but right now it's unpredictable whether read-key returns "7" for a C-g or signals a quit, at least when you use X and your timing is a bit off. The observed behavior is this: If I suspend Emacs while it's in (read-key), type C-g in the suspended window, and unsuspend it, I usually get a quit. If I don't, I seem to always get a 7. (This is probably because the focus-in event and the quit event arrive simultaneously, as far as read_char is concerned). There are so many small buglets and unexplained oddities in this code that I think an overhaul is needed. We should probably open a new bug for the general topic of how C-g relates to various kinds of quitting (normal, urgent, emergency escape), and how it can be simplified (why do we still have getcjmp? Is it for the MSDOS port exclusively?) However, opening that bug would ideally involve a somewhat complete description of the current, chaotic situation (read-key isn't the only function that makes it depend on timing, or timers, how quits are handled). And that takes some time. I mean things like "sometimes unread-command-events get looked up in special-event-map, but usually they don't". But I suggest we fix the original easily-fixed sit-for bug in one of the various minimally invasive ways we've found, and start out with a fresh bug. The current discussion is impossible for anyone else to read. Pip From unknown Thu Jun 19 16:22:25 2025 X-Loop: help-debbugs@gnu.org Subject: bug#78737: sit-for behavior changes when byte-compiled Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Jun 2025 20:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 78737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 78737@debbugs.gnu.org, pipcet@protonmail.com, dancol@dancol.org Received: via spool by 78737-submit@debbugs.gnu.org id=B78737.17500177962179 (code B ref 78737); Sun, 15 Jun 2025 20:04:01 +0000 Received: (at 78737) by debbugs.gnu.org; 15 Jun 2025 20:03:16 +0000 Received: from localhost ([127.0.0.1]:33008 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uQtZT-0000Z0-U3 for submit@debbugs.gnu.org; Sun, 15 Jun 2025 16:03:16 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47526) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uQtZR-0000YB-00 for 78737@debbugs.gnu.org; Sun, 15 Jun 2025 16:03:14 -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 1uQtZD-000085-US; Sun, 15 Jun 2025 16:03:06 -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=QIFDJ8RYx2mxIwoGhGHZLS3XaMbt70uaRkajz05tXjo=; b=RS45/ohqo6L1 bSlkM2z6AKviUfFd8BqnnLRu7LTEEPRheIaPYWf2JusOTRAsi9shJvmPTzQlCqTBojor4froFtuQ0 pGgmgTP7IYSWGFjN+uSzqskFkoQYBYiCcBQx6z+5z8lFFPD4tasafkiz8sqPKxDZHXNQZVLlh0WLG AJSHcMfulV/TGi5oIi4Ny2t7jcZJlS2vkGdZ4vqz9ffTwlOG881VLJsLpqhF76uGMyx5vbflqM6dj dPFWhW0JqiTxX4RsK0kTU/wl5kc5XxUJk2IhUfi0W3C++HUYtGwT0OIUeRMPZNZAWlCXY6/ogYNqk 55zEZ5AaCwSas0CvhhYjHQ==; Date: Sun, 15 Jun 2025 23:02:53 +0300 Message-Id: <86ldpspyc2.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Stefan Monnier on Sun, 15 Jun 2025 14:03:16 -0400) References: <87bjqu1ho9.fsf@protonmail.com> <86y0tvd3xy.fsf@gnu.org> <868qluu9ev.fsf@gnu.org> <87y0tuvn15.fsf@protonmail.com> <86sek2sp20.fsf@gnu.org> <86plf6sn4s.fsf@gnu.org> X-Spam-Score: -2.3 (--) 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 (---) > From: Stefan Monnier > Cc: pipcet@protonmail.com, 78737@debbugs.gnu.org, dancol@dancol.org > Date: Sun, 15 Jun 2025 14:03:16 -0400 > > > It seems this feature was originally known as "immediate quit". > > At some point the immediate_quit variable itself was removed, but the > > term seems appropriate regardless. So I suggest that's how we > > call it. > > Hmm... I thought the `immediate_quit` variable was used for yet another > notion of "immediate quit". Maybe I'm confused. It was used for interrupting potentially long operations. The mechanism had some subtle problems, so it was removed, but as result we lost some of the abilities to break out of prolonged operations.