GNU bug report logs - #78737
sit-for behavior changes when byte-compiled

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: Daniel Colascione <dancol@HIDDEN>; dated Mon, 9 Jun 2025 20:50:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:09:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 11:09:46 2025
Received: from localhost ([127.0.0.1]:48050 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ62L-0008Nw-Vo
	for submit <at> 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 <monnier@HIDDEN>)
 id 1uQ62J-0008Nj-Uk
 for 78737 <at> 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 <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86y0twerm0.fsf@HIDDEN>
Message-ID: <jwv1prn8ys0.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN>
 <87sek5ysbs.fsf@HIDDEN> <86bjqsgbtx.fsf@HIDDEN>
 <AF88B62D-A04C-4276-90EF-6BA8DFD7CF3C@HIDDEN>
 <865xh0gapx.fsf@HIDDEN>
 <79889093-562A-45E6-ACF2-72662956F3CA@HIDDEN>
 <86y0twerm0.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN,
 Daniel Colascione <dancol@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:04:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 11:04:40 2025
Received: from localhost ([127.0.0.1]:47907 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5xP-0007u2-Q0
	for submit <at> 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 <monnier@HIDDEN>)
 id 1uQ5xN-0007tp-Ol
 for 78737 <at> 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 <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86jz5ie7j7.fsf@HIDDEN>
Message-ID: <jwv7c1f8z9r.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <86jz5ie7j7.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, dancol@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 15:04:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 11:04:02 2025
Received: from localhost ([127.0.0.1]:47888 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5wo-0007ru-2y
	for submit <at> 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 <dancol@HIDDEN>) id 1uQ5wk-0007rR-Jq
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uQ5vG-00BttG-0I;
 Fri, 13 Jun 2025 11:02:27 -0400
Date: Fri, 13 Jun 2025 08:00:04 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>, Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <86a56belov.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <86tt4kdw7r.fsf@HIDDEN> <87v7ozygih.fsf@HIDDEN>
 <86a56belov.fsf@HIDDEN>
Message-ID: <7C75C53D-FB46-42D2-BECC-BB1F5BBCABF1@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On June 13, 2025 7:54:40 AM PDT, Eli Zaretskii <eliz@gnu=2Eorg> wrote:
>> Date: Fri, 13 Jun 2025 12:26:19 +0000
>> From: Pip Cet <pipcet@protonmail=2Ecom>
>> Cc: dancol@dancol=2Eorg, monnier@iro=2Eumontreal=2Eca, 78737@debbugs=2E=
gnu=2Eorg
>>=20
>> "Eli Zaretskii" <eliz@gnu=2Eorg> 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:54:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:54:55 2025
Received: from localhost ([127.0.0.1]:47649 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5nx-00077t-AB
	for submit <at> 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 <eliz@HIDDEN>) id 1uQ5ns-00076I-20
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87v7ozygih.fsf@HIDDEN> (message from Pip Cet on Fri, 13
 Jun 2025 12:26:19 +0000)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <86tt4kdw7r.fsf@HIDDEN> <87v7ozygih.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, dancol@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Fri, 13 Jun 2025 12:26:19 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: dancol@HIDDEN, monnier@HIDDEN, 78737 <at> debbugs.gnu.org
> 
> "Eli Zaretskii" <eliz@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:53:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:53:56 2025
Received: from localhost ([127.0.0.1]:47626 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5n1-00073R-NO
	for submit <at> 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 <monnier@HIDDEN>)
 id 1uQ5mz-00073E-DE
 for 78737 <at> 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 <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <875xh21f2w.fsf@HIDDEN>
Message-ID: <jwvikkz907o.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <875xh21f2w.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Daniel Colascione <dancol@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:51:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:51:56 2025
Received: from localhost ([127.0.0.1]:47560 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5l5-0006wP-Mb
	for submit <at> 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 <monnier@HIDDEN>)
 id 1uQ5l2-0006up-Bv
 for 78737 <at> 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 <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <87bjqu1ho9.fsf@HIDDEN>
Message-ID: <jwvecvn8zrh.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <87bjqu1ho9.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Daniel Colascione <dancol@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:49:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:49:24 2025
Received: from localhost ([127.0.0.1]:47522 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5id-0006iZ-Tt
	for submit <at> 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 <dancol@HIDDEN>) id 1uQ5ib-0006iP-QS
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uQ5h7-00Btqf-2o;
 Fri, 13 Jun 2025 10:47:50 -0400
Date: Fri, 13 Jun 2025 07:48:54 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <86cyb7em26.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <86tt4kdw7r.fsf@HIDDEN> <m1zfeckrgd.fsf@HIDDEN> <86ecvneuut.fsf@HIDDEN>
 <8A57564E-70F3-49F6-8D77-1C947087DF8C@HIDDEN> <86cyb7em26.fsf@HIDDEN>
Message-ID: <CD59BDD2-3DA1-4A8A-8E22-B7D68AC5F438@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On June 13, 2025 7:46:41 AM PDT, Eli Zaretskii <eliz@gnu=2Eorg> wrote:
>> Date: Fri, 13 Jun 2025 04:49:21 -0700
>> From: Daniel Colascione <dancol@dancol=2Eorg>
>> 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 <eliz@gnu=2Eorg> wrote:
>> >> From: Daniel Colascione <dancol@dancol=2Eorg>
>> >> Cc: Pip Cet <pipcet@protonmail=2Ecom>,  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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:46:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:46:58 2025
Received: from localhost ([127.0.0.1]:47498 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5gI-0006cP-3D
	for submit <at> 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 <eliz@HIDDEN>) id 1uQ5g9-0006br-4G
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <8A57564E-70F3-49F6-8D77-1C947087DF8C@HIDDEN> (message from
 Daniel Colascione on Fri, 13 Jun 2025 04:49:21 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <86tt4kdw7r.fsf@HIDDEN> <m1zfeckrgd.fsf@HIDDEN> <86ecvneuut.fsf@HIDDEN>
 <8A57564E-70F3-49F6-8D77-1C947087DF8C@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Fri, 13 Jun 2025 04:49:21 -0700
> From: Daniel Colascione <dancol@HIDDEN>
> CC: pipcet@HIDDEN, monnier@HIDDEN, 78737 <at> debbugs.gnu.org
> 
> 
> 
> On June 13, 2025 4:36:42 AM PDT, Eli Zaretskii <eliz@HIDDEN> wrote:
> >> From: Daniel Colascione <dancol@HIDDEN>
> >> Cc: Pip Cet <pipcet@HIDDEN>,  monnier@HIDDEN,
> >>   78737 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:39:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:39:15 2025
Received: from localhost ([127.0.0.1]:47425 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5Yp-00067U-Ip
	for submit <at> 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 <gerd.moellmann@HIDDEN>)
 id 1uQ5Yn-00067G-89
 for 78737 <at> 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 <at> 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: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <24B8C58B-D7CE-4596-A685-867B49EE4343@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <m14iwkokx9.fsf@HIDDEN> <86sek4duov.fsf@HIDDEN>
 <CAM=F=bAq+cFwo9sJ+LZjp6XTq4Z7c6=C25Pz1fNR_VVoKbeY7w@HIDDEN>
 <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@HIDDEN>
 <m2h60jkag2.fsf@HIDDEN>
 <24B8C58B-D7CE-4596-A685-867B49EE4343@HIDDEN>
Date: Fri, 13 Jun 2025 16:39:05 +0200
Message-ID: <m2cyb7k8om.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Pip Cet <pipcet@HIDDEN>, Lynn Winebarger <owinebar@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Daniel Colascione <dancol@HIDDEN> writes:

> On June 13, 2025 7:01:01 AM PDT, "Gerd M=C3=B6llmann" <gerd.moellmann@gma=
il.com> wrote:
>>Daniel Colascione <dancol@HIDDEN> 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 :-(.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:37:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:37:12 2025
Received: from localhost ([127.0.0.1]:47401 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5Wp-00062Z-Pc
	for submit <at> 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 <dancol@HIDDEN>) id 1uQ5Wm-00062P-7o
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uQ5VO-00Btnk-0W;
 Fri, 13 Jun 2025 10:35:43 -0400
Date: Fri, 13 Jun 2025 07:36:57 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <jwvo6ur9170.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN> <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <m1ecvr8k6t.fsf@HIDDEN>
 <jwvo6ur9170.fsf-monnier+emacs@HIDDEN>
Message-ID: <48D49344-799D-4680-A49C-373282B4F90B@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On June 13, 2025 7:28:23 AM PDT, Stefan Monnier <monnier@iro=2Eumontreal=2E=
ca> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:28:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:28:36 2025
Received: from localhost ([127.0.0.1]:47181 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ5OV-0005Ky-N0
	for submit <at> 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 <monnier@HIDDEN>)
 id 1uQ5OT-0005Kg-Rh
 for 78737 <at> 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 <monnier@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <m1ecvr8k6t.fsf@HIDDEN>
Message-ID: <jwvo6ur9170.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <m1ecvr8k6t.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:13:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:13:04 2025
Received: from localhost ([127.0.0.1]:46760 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ59T-00046k-N5
	for submit <at> 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 <dancol@HIDDEN>) id 1uQ59Q-00046C-Sr
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uQ584-00Btiw-1y;
 Fri, 13 Jun 2025 10:11:36 -0400
Date: Fri, 13 Jun 2025 07:12:56 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: =?ISO-8859-1?Q?Gerd_M=F6llmann?= <gerd.moellmann@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <m2h60jkag2.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <m14iwkokx9.fsf@HIDDEN> <86sek4duov.fsf@HIDDEN>
 <CAM=F=bAq+cFwo9sJ+LZjp6XTq4Z7c6=C25Pz1fNR_VVoKbeY7w@HIDDEN>
 <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@HIDDEN> <m2h60jkag2.fsf@HIDDEN>
Message-ID: <24B8C58B-D7CE-4596-A685-867B49EE4343@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Pip Cet <pipcet@HIDDEN>, Lynn Winebarger <owinebar@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



On June 13, 2025 7:01:01 AM PDT, "Gerd M=C3=B6llmann" <gerd=2Emoellmann@gm=
ail=2Ecom> wrote:
>Daniel Colascione <dancol@dancol=2Eorg> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:02:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:02:26 2025
Received: from localhost ([127.0.0.1]:46582 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ4zB-0003Pl-Pr
	for submit <at> 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 <dancol@HIDDEN>) id 1uQ4z8-0003Pb-CP
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uQ4xm-00Btfo-0c;
 Fri, 13 Jun 2025 10:00:58 -0400
Date: Fri, 13 Jun 2025 07:02:14 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Lynn Winebarger <owinebar@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <m14iwkokx9.fsf@HIDDEN> <86sek4duov.fsf@HIDDEN>
 <CAM=F=bAq+cFwo9sJ+LZjp6XTq4Z7c6=C25Pz1fNR_VVoKbeY7w@HIDDEN>
 <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@HIDDEN>
Message-ID: <37BCCFA8-8EFC-4BB1-8B4F-D805FB7E1B6A@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



On June 13, 2025 6:42:58 AM PDT, Daniel Colascione <dancol@dancol=2Eorg> w=
rote:
>
>
>On June 13, 2025 5:23:34 AM PDT, Lynn Winebarger <owinebar@gmail=2Ecom> w=
rote:
>>On Fri, Jun 13, 2025, 2:26=E2=80=AFAM Eli Zaretskii <eliz@gnu=2Eorg> wro=
te:
>>
>>> > From: Daniel Colascione <dancol@dancol=2Eorg>
>>> > Cc: Eli Zaretskii <eliz@gnu=2Eorg>,  monnier@iro=2Eumontreal=2Eca,
>>> >   78737@debbugs=2Egnu=2Eorg
>>> > Date: Thu, 12 Jun 2025 11:48:50 -0700
>>> >
>>> > Pip Cet <pipcet@protonmail=2Ecom> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 14:01:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:01:14 2025
Received: from localhost ([127.0.0.1]:46578 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ4y2-0003Ns-8y
	for submit <at> 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 <gerd.moellmann@HIDDEN>)
 id 1uQ4xz-0003NN-2L
 for 78737 <at> 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 <at> 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: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <m14iwkokx9.fsf@HIDDEN> <86sek4duov.fsf@HIDDEN>
 <CAM=F=bAq+cFwo9sJ+LZjp6XTq4Z7c6=C25Pz1fNR_VVoKbeY7w@HIDDEN>
 <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@HIDDEN>
Date: Fri, 13 Jun 2025 16:01:01 +0200
Message-ID: <m2h60jkag2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Pip Cet <pipcet@HIDDEN>, Lynn Winebarger <owinebar@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Daniel Colascione <dancol@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 13:43:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 09:43:06 2025
Received: from localhost ([127.0.0.1]:45216 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ4gU-0001rX-0V
	for submit <at> 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 <dancol@HIDDEN>) id 1uQ4gP-0001qW-R7
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uQ4f3-00BtcX-1Y;
 Fri, 13 Jun 2025 09:41:37 -0400
Date: Fri, 13 Jun 2025 06:42:58 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Lynn Winebarger <owinebar@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <CAM=F=bAq+cFwo9sJ+LZjp6XTq4Z7c6=C25Pz1fNR_VVoKbeY7w@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <m14iwkokx9.fsf@HIDDEN> <86sek4duov.fsf@HIDDEN>
 <CAM=F=bAq+cFwo9sJ+LZjp6XTq4Z7c6=C25Pz1fNR_VVoKbeY7w@HIDDEN>
Message-ID: <9FF3BAF7-2C9F-4F19-8104-4FDC4DB2BF97@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



On June 13, 2025 5:23:34 AM PDT, Lynn Winebarger <owinebar@gmail=2Ecom> wr=
ote:
>On Fri, Jun 13, 2025, 2:26=E2=80=AFAM Eli Zaretskii <eliz@gnu=2Eorg> wrot=
e:
>
>> > From: Daniel Colascione <dancol@dancol=2Eorg>
>> > Cc: Eli Zaretskii <eliz@gnu=2Eorg>,  monnier@iro=2Eumontreal=2Eca,
>> >   78737@debbugs=2Egnu=2Eorg
>> > Date: Thu, 12 Jun 2025 11:48:50 -0700
>> >
>> > Pip Cet <pipcet@protonmail=2Ecom> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 13:36:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 09:36:10 2025
Received: from localhost ([127.0.0.1]:45038 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ4Ze-0001Mi-1E
	for submit <at> 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 <dancol@HIDDEN>) id 1uQ4ZZ-0001MS-QD
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uQ4Y1-00BtaH-2z;
 Fri, 13 Jun 2025 09:34:22 -0400
Date: Fri, 13 Jun 2025 06:35:40 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <86frg3euz5.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <m14iwkokx9.fsf@HIDDEN> <86sek4duov.fsf@HIDDEN>
 <m1ecvom76a.fsf@HIDDEN> <86frg3euz5.fsf@HIDDEN>
Message-ID: <CF455BD2-21B5-42CC-98DC-3A5BE4E9CE3B@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



On June 13, 2025 4:34:06 AM PDT, Eli Zaretskii <eliz@gnu=2Eorg> wrote:
>> From: Daniel Colascione <dancol@dancol=2Eorg>
>> 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 <eliz@gnu=2Eorg> writes:
>>=20
>> >> From: Daniel Colascione <dancol@dancol=2Eorg>
>> >> Cc: Eli Zaretskii <eliz@gnu=2Eorg>,  monnier@iro=2Eumontreal=2Eca,
>> >>   78737@debbugs=2Egnu=2Eorg
>> >> Date: Thu, 12 Jun 2025 11:48:50 -0700
>> >>=20
>> >> Pip Cet <pipcet@protonmail=2Ecom> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 12:26:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 08:26:32 2025
Received: from localhost ([127.0.0.1]:43949 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ3UN-0005Al-JN
	for submit <at> 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 <pipcet@HIDDEN>)
 id 1uQ3UK-0005AV-P0
 for 78737 <at> 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
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Message-ID: <87v7ozygih.fsf@HIDDEN>
In-Reply-To: <86tt4kdw7r.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <86tt4kdw7r.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, dancol@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Eli Zaretskii" <eliz@HIDDEN> writes:

>> Date: Thu, 12 Jun 2025 18:37:58 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: dancol@HIDDEN, monnier@HIDDEN, 78737 <at> debbugs.gnu.org
>>
>> "Eli Zaretskii" <eliz@HIDDEN> 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 12:24:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 08:24:00 2025
Received: from localhost ([127.0.0.1]:43896 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ3Rv-0004vv-AQ
	for submit <at> 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 <owinebar@HIDDEN>)
 id 1uQ3Rr-0004vZ-0l
 for 78737 <at> 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 <at> 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: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN>
 <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <m14iwkokx9.fsf@HIDDEN> <86sek4duov.fsf@HIDDEN>
In-Reply-To: <86sek4duov.fsf@HIDDEN>
From: Lynn Winebarger <owinebar@HIDDEN>
Date: Fri, 13 Jun 2025 08:23:34 -0400
X-Gm-Features: AX0GCFuvjmj0zAjSP6BF3-ufhmWCUgMG-7n_cF8umsSoeat0XJJyrZC4nQNZ9Ig
Message-ID: <CAM=F=bAq+cFwo9sJ+LZjp6XTq4Z7c6=C25Pz1fNR_VVoKbeY7w@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000003491200637731e85"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
 Daniel Colascione <dancol@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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 <eliz@HIDDEN> wrote:

> > From: Daniel Colascione <dancol@HIDDEN>
> > Cc: Eli Zaretskii <eliz@HIDDEN>,  monnier@HIDDEN,
> >   78737 <at> debbugs.gnu.org
> > Date: Thu, 12 Jun 2025 11:48:50 -0700
> >
> > Pip Cet <pipcet@HIDDEN> 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

<div dir=3D"auto"><div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Fri, Jun 13, 2025, 2:26=E2=80=AFAM Eli Zaretskii &lt;<a hre=
f=3D"mailto:eliz@HIDDEN" target=3D"_blank" rel=3D"noreferrer">eliz@HIDDEN=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=
&gt; From: Daniel Colascione &lt;<a href=3D"mailto:dancol@HIDDEN" rel=
=3D"noreferrer noreferrer" target=3D"_blank">dancol@HIDDEN</a>&gt;<br>
&gt; Cc: Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN" rel=3D"noreferre=
r noreferrer" target=3D"_blank">eliz@HIDDEN</a>&gt;,=C2=A0 <a href=3D"mail=
to:monnier@HIDDEN" rel=3D"noreferrer noreferrer" target=3D"_blank=
">monnier@HIDDEN</a>,<br>
&gt;=C2=A0 =C2=A0<a href=3D"mailto:78737 <at> debbugs.gnu.org" rel=3D"noreferrer=
 noreferrer" target=3D"_blank">78737 <at> debbugs.gnu.org</a><br>
&gt; Date: Thu, 12 Jun 2025 11:48:50 -0700<br>
&gt; <br>
&gt; Pip Cet &lt;<a href=3D"mailto:pipcet@HIDDEN" rel=3D"noreferrer=
 noreferrer" target=3D"_blank">pipcet@HIDDEN</a>&gt; writes:<br>
&gt; <br>
&gt; &gt; I&#39;d like read-event, when called while inhibit-quit is t, to =
report<br>
&gt; &gt; quits by setting quit-flag in addition to returning quit_char: it=
&#39;ll<br>
&gt; &gt; simplify the C code, and it would make<br>
&gt; &gt;<br>
&gt; &gt; (while t<br>
&gt; &gt;=C2=A0 =C2=A0(let ((inhibit-quit t))<br>
&gt; &gt;=C2=A0 =C2=A0 =C2=A0(read-event)))<br>
&gt; <br>
&gt; I strongly disagree.=C2=A0 read-event should read an event.<br>
&gt; Setting quit-flag by side effect when it happens to read one key and n=
ot<br>
&gt; others makes the interface less regular and understandable.<br>
<br>
We should start by agreeing that the capability of interrupting a<br>
running Lisp program is a real need.=C2=A0 Are we in agreement about that?<=
br>
If not, let&#39;s first hear the arguments why not.<br>
<br>
If we _are_ in agreement about that, we should discuss how this should<br>
be possible if read-event (and perhaps others?) return C-g instead of<br>
raising quit-flag.=C2=A0 The alternatives mentioned until now are:<br>
<br>
=C2=A0. restore the old behavior, whereby C-g interrupts read-event<br>
=C2=A0. have a variable that, if set, will restore the old behavior in<br>
=C2=A0 =C2=A0read-event and other affected primitives, to be interruptible =
by a<br>
=C2=A0 =C2=A0single C-g<br>
=C2=A0. make two C-g presses &quot;in quick succession&quot; set quit-flag,=
 IOW<br>
=C2=A0 =C2=A0&quot;C-g C-g&quot; will have the same effect as C-g previousl=
y<br>
<br>
Are there other alternatives?<br></blockquote></div></div><div dir=3D"auto"=
><br></div><div dir=3D"auto">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 &quot;interrupts&quot;?=C2=A0 The key strokes =
would be processed by C machinery and never seen directly by lisp code and =
not be considered &quot;events&quot;.</div><div dir=3D"auto">Then C-g could=
 be bound to a thunk signalling quit, and the effect of &quot;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 &quot;special&quot; without=
 resorting to read-event.=C2=A0 For example, this read-event call in term.e=
l:</div><div dir=3D"auto">(message &quot;Hit space to flush&quot;)</div><di=
v dir=3D"auto">=C2=A0 =C2=A0 =C2=A0 (let ((ch (read-event)))</div><div dir=
=3D"auto">=C2=A0(if (eq ch ?\s)</div><div dir=3D"auto">=C2=A0 =C2=A0 =C2=A0=
(set-window-configuration conf)</div><div dir=3D"auto">=C2=A0 =C2=A0(push c=
h unread-command-events)))</div><div dir=3D"auto"><br></div><div dir=3D"aut=
o">Could be replaced by something like</div><div dir=3D"auto">(with-interru=
pts ((?\s (signal term-flush)))</div><div dir=3D"auto">=C2=A0 (condition-ca=
se nil</div><div dir=3D"auto">=C2=A0 =C2=A0 (while t (sit-for 100))</div><d=
iv dir=3D"auto">=C2=A0 =C2=A0 =C2=A0(term-flush (set-window-configuration c=
onf))))</div><div dir=3D"auto"><br></div><div dir=3D"auto">Then some of the=
se use-case concerns could be mooted altogether.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Lynn</div><div dir=3D"auto"><br></div></div>

--0000000000003491200637731e85--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 11:49:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 07:49:40 2025
Received: from localhost ([127.0.0.1]:43128 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ2ue-0002P9-0F
	for submit <at> 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 <dancol@HIDDEN>) id 1uQ2ua-0002Oz-9d
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uQ2t7-00BtIP-1x;
 Fri, 13 Jun 2025 07:48:01 -0400
Date: Fri, 13 Jun 2025 04:49:21 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <86ecvneuut.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <86tt4kdw7r.fsf@HIDDEN> <m1zfeckrgd.fsf@HIDDEN> <86ecvneuut.fsf@HIDDEN>
Message-ID: <8A57564E-70F3-49F6-8D77-1C947087DF8C@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



On June 13, 2025 4:36:42 AM PDT, Eli Zaretskii <eliz@gnu=2Eorg> wrote:
>> From: Daniel Colascione <dancol@dancol=2Eorg>
>> Cc: Pip Cet <pipcet@protonmail=2Ecom>,  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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 11:37:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 07:37:00 2025
Received: from localhost ([127.0.0.1]:42864 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ2iP-0001UA-VF
	for submit <at> 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 <eliz@HIDDEN>) id 1uQ2iL-0001Ss-58
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <m1zfeckrgd.fsf@HIDDEN> (message from Daniel Colascione on
 Fri, 13 Jun 2025 00:53:38 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <86tt4kdw7r.fsf@HIDDEN> <m1zfeckrgd.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Daniel Colascione <dancol@HIDDEN>
> Cc: Pip Cet <pipcet@HIDDEN>,  monnier@HIDDEN,
>   78737 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 11:34:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 07:34:20 2025
Received: from localhost ([127.0.0.1]:42820 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uQ2fr-0001Eu-A6
	for submit <at> 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 <eliz@HIDDEN>) id 1uQ2fn-0001Ec-Ff
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <m1ecvom76a.fsf@HIDDEN> (message from Daniel Colascione on
 Fri, 13 Jun 2025 00:28:45 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <m14iwkokx9.fsf@HIDDEN> <86sek4duov.fsf@HIDDEN>
 <m1ecvom76a.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Daniel Colascione <dancol@HIDDEN>
> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737 <at> debbugs.gnu.org
> Date: Fri, 13 Jun 2025 00:28:45 -0700
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> From: Daniel Colascione <dancol@HIDDEN>
> >> Cc: Eli Zaretskii <eliz@HIDDEN>,  monnier@HIDDEN,
> >>   78737 <at> debbugs.gnu.org
> >> Date: Thu, 12 Jun 2025 11:48:50 -0700
> >> 
> >> Pip Cet <pipcet@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 07:53:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 03:53:55 2025
Received: from localhost ([127.0.0.1]:38333 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPzEY-0002QD-Oq
	for submit <at> 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 <dancol@HIDDEN>) id 1uPzEU-0002Py-P1
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPzCz-00BsUD-1P;
 Fri, 13 Jun 2025 03:52:17 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86tt4kdw7r.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <86tt4kdw7r.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Fri, 13 Jun 2025 00:53:38 -0700
Message-ID: <m1zfeckrgd.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
 monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> Date: Thu, 12 Jun 2025 18:37:58 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: dancol@HIDDEN, monnier@HIDDEN, 78737 <at> debbugs.gnu.org
>>=20
>> "Eli Zaretskii" <eliz@HIDDEN> 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.





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 07:29:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 03:29:06 2025
Received: from localhost ([127.0.0.1]:37672 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPyqX-0008TD-A5
	for submit <at> 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 <dancol@HIDDEN>) id 1uPyqP-0008RX-4n
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPyou-00Bs13-1H;
 Fri, 13 Jun 2025 03:27:24 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86sek4duov.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <m14iwkokx9.fsf@HIDDEN> <86sek4duov.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Fri, 13 Jun 2025 00:28:45 -0700
Message-ID: <m1ecvom76a.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Daniel Colascione <dancol@HIDDEN>
>> Cc: Eli Zaretskii <eliz@HIDDEN>,  monnier@HIDDEN,
>>   78737 <at> debbugs.gnu.org
>> Date: Thu, 12 Jun 2025 11:48:50 -0700
>> 
>> Pip Cet <pipcet@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 06:25:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 02:25:54 2025
Received: from localhost ([127.0.0.1]:37477 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPxrM-0004xj-DX
	for submit <at> 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 <eliz@HIDDEN>) id 1uPxrG-0004vg-K1
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <m14iwkokx9.fsf@HIDDEN> (message from Daniel Colascione on
 Thu, 12 Jun 2025 11:48:50 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
 <m14iwkokx9.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Daniel Colascione <dancol@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>,  monnier@HIDDEN,
>   78737 <at> debbugs.gnu.org
> Date: Thu, 12 Jun 2025 11:48:50 -0700
> 
> Pip Cet <pipcet@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 13 Jun 2025 05:52:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 01:52:56 2025
Received: from localhost ([127.0.0.1]:37389 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPxLS-0007Fs-Ag
	for submit <at> 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 <eliz@HIDDEN>) id 1uPxLN-0007ES-LH
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <875xh0ztz2.fsf@HIDDEN> (message from Pip Cet on Thu, 12
 Jun 2025 18:37:58 +0000)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, dancol@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Thu, 12 Jun 2025 18:37:58 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: dancol@HIDDEN, monnier@HIDDEN, 78737 <at> debbugs.gnu.org
> 
> "Eli Zaretskii" <eliz@HIDDEN> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 19:07:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 15:07:45 2025
Received: from localhost ([127.0.0.1]:60516 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPnH7-0007Xw-62
	for submit <at> 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 <dancol@HIDDEN>) id 1uPnH3-0007Xi-4x
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPnFb-00Bp6t-1e;
 Thu, 12 Jun 2025 15:06:11 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86y0twerm0.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN>
 <87sek5ysbs.fsf@HIDDEN> <86bjqsgbtx.fsf@HIDDEN>
 <AF88B62D-A04C-4276-90EF-6BA8DFD7CF3C@HIDDEN>
 <865xh0gapx.fsf@HIDDEN>
 <79889093-562A-45E6-ACF2-72662956F3CA@HIDDEN>
 <86y0twerm0.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Thu, 12 Jun 2025 12:07:32 -0700
Message-ID: <m1y0twn5hn.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> Date: Thu, 12 Jun 2025 11:04:06 -0700
>> From: Daniel Colascione <dancol@HIDDEN>
>> CC: pipcet@HIDDEN, monnier@HIDDEN, 78737 <at> debbugs.gnu.org
>> 
>> 
>> 
>> On June 12, 2025 9:56:26 AM PDT, Eli Zaretskii <eliz@HIDDEN> wrote:
>> >> Date: Thu, 12 Jun 2025 09:52:22 -0700
>> >> From: Daniel Colascione <dancol@HIDDEN>
>> >> CC: monnier@HIDDEN, 78737 <at> debbugs.gnu.org
>> >> 
>> >> 
>> >> 
>> >> On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii <eliz@HIDDEN> wrote:
>> >> >> Date: Thu, 12 Jun 2025 13:58:51 +0000
>> >> >> From: Pip Cet <pipcet@HIDDEN>
>> >> >> Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, 78737 <at> 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 <whether we've received N_emergency quits
  in last T_emergency milliseconds>;
}

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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 18:49:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 14:49:01 2025
Received: from localhost ([127.0.0.1]:60393 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPmyy-0006G0-Nh
	for submit <at> 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 <dancol@HIDDEN>) id 1uPmyw-0006Fb-8n
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPmxV-00Bosn-1S;
 Thu, 12 Jun 2025 14:47:29 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <875xh0ztz2.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <875xh0ztz2.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Thu, 12 Jun 2025 11:48:50 -0700
Message-ID: <m14iwkokx9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Pip Cet <pipcet@HIDDEN> writes:

> "Eli Zaretskii" <eliz@HIDDEN> writes:
>
>>> Date: Thu, 12 Jun 2025 13:58:51 +0000
>>> From: Pip Cet <pipcet@HIDDEN>
>>> Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, 78737 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 18:38:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 14:38:14 2025
Received: from localhost ([127.0.0.1]:60362 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPmoX-0005ZY-Mn
	for submit <at> 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 <pipcet@HIDDEN>)
 id 1uPmoV-0005Ys-Ux
 for 78737 <at> 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
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Message-ID: <875xh0ztz2.fsf@HIDDEN>
In-Reply-To: <86bjqsgbtx.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, dancol@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Eli Zaretskii" <eliz@HIDDEN> writes:

>> Date: Thu, 12 Jun 2025 13:58:51 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 18:34:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 14:34:49 2025
Received: from localhost ([127.0.0.1]:60345 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPmlE-0005JD-Pp
	for submit <at> 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 <eliz@HIDDEN>) id 1uPmlB-0005Ip-Rk
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <79889093-562A-45E6-ACF2-72662956F3CA@HIDDEN> (message from
 Daniel Colascione on Thu, 12 Jun 2025 11:04:06 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <AF88B62D-A04C-4276-90EF-6BA8DFD7CF3C@HIDDEN>
 <865xh0gapx.fsf@HIDDEN> <79889093-562A-45E6-ACF2-72662956F3CA@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Thu, 12 Jun 2025 11:04:06 -0700
> From: Daniel Colascione <dancol@HIDDEN>
> CC: pipcet@HIDDEN, monnier@HIDDEN, 78737 <at> debbugs.gnu.org
> 
> 
> 
> On June 12, 2025 9:56:26 AM PDT, Eli Zaretskii <eliz@HIDDEN> wrote:
> >> Date: Thu, 12 Jun 2025 09:52:22 -0700
> >> From: Daniel Colascione <dancol@HIDDEN>
> >> CC: monnier@HIDDEN, 78737 <at> debbugs.gnu.org
> >> 
> >> 
> >> 
> >> On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii <eliz@HIDDEN> wrote:
> >> >> Date: Thu, 12 Jun 2025 13:58:51 +0000
> >> >> From: Pip Cet <pipcet@HIDDEN>
> >> >> Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, 78737 <at> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 18:04:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 14:04:22 2025
Received: from localhost ([127.0.0.1]:60208 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPmHl-0003Ge-NQ
	for submit <at> 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 <dancol@HIDDEN>) id 1uPmHi-0003GJ-4X
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPmGF-00BoRf-0v;
 Thu, 12 Jun 2025 14:02:47 -0400
Date: Thu, 12 Jun 2025 11:04:06 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <865xh0gapx.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <AF88B62D-A04C-4276-90EF-6BA8DFD7CF3C@HIDDEN>
 <865xh0gapx.fsf@HIDDEN>
Message-ID: <79889093-562A-45E6-ACF2-72662956F3CA@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



On June 12, 2025 9:56:26 AM PDT, Eli Zaretskii <eliz@gnu=2Eorg> wrote:
>> Date: Thu, 12 Jun 2025 09:52:22 -0700
>> From: Daniel Colascione <dancol@dancol=2Eorg>
>> CC: monnier@iro=2Eumontreal=2Eca, 78737@debbugs=2Egnu=2Eorg
>>=20
>>=20
>>=20
>> On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii <eliz@gnu=2Eorg> wrote:
>> >> Date: Thu, 12 Jun 2025 13:58:51 +0000
>> >> From: Pip Cet <pipcet@protonmail=2Ecom>
>> >> Cc: Eli Zaretskii <eliz@gnu=2Eorg>, 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 17:47:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 13:47:10 2025
Received: from localhost ([127.0.0.1]:60127 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPm17-00027Q-Qj
	for submit <at> 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 <dancol@HIDDEN>) id 1uPm14-000277-SG
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPlzb-00BoHZ-0y;
 Thu, 12 Jun 2025 13:45:35 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <87ikl1ym6m.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <m1msadowmw.fsf@HIDDEN> <87ikl1ym6m.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Thu, 12 Jun 2025 10:46:56 -0700
Message-ID: <m1ikl0onsf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Pip Cet <pipcet@HIDDEN> writes:

> 1"Daniel Colascione" <dancol@HIDDEN> writes:
>
>> Pip Cet <pipcet@HIDDEN> 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=<optimized out>) at keyboard.c:12400
> #3  0x000055555570cfca in deliver_process_signal (sig=2, handler=0x5555556eab10 <handle_interrupt_signal>) at sysdep.c:1751
> #4  0x00007ffff5adaed0 in <signal handler called> () 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 16:56:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 12:56:38 2025
Received: from localhost ([127.0.0.1]:59904 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPlEE-00076z-0g
	for submit <at> 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 <eliz@HIDDEN>) id 1uPlEA-00076Y-Jq
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <AF88B62D-A04C-4276-90EF-6BA8DFD7CF3C@HIDDEN> (message from
 Daniel Colascione on Thu, 12 Jun 2025 09:52:22 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN> <AF88B62D-A04C-4276-90EF-6BA8DFD7CF3C@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Thu, 12 Jun 2025 09:52:22 -0700
> From: Daniel Colascione <dancol@HIDDEN>
> CC: monnier@HIDDEN, 78737 <at> debbugs.gnu.org
> 
> 
> 
> On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii <eliz@HIDDEN> wrote:
> >> Date: Thu, 12 Jun 2025 13:58:51 +0000
> >> From: Pip Cet <pipcet@HIDDEN>
> >> Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, 78737 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 16:52:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 12:52:36 2025
Received: from localhost ([127.0.0.1]:59882 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPlAJ-0006pB-E8
	for submit <at> 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 <dancol@HIDDEN>) id 1uPlAG-0006oo-BW
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPl8p-00BnFA-00;
 Thu, 12 Jun 2025 12:51:03 -0400
Date: Thu, 12 Jun 2025 09:52:22 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>, Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <86bjqsgbtx.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <86bjqsgbtx.fsf@HIDDEN>
Message-ID: <AF88B62D-A04C-4276-90EF-6BA8DFD7CF3C@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii <eliz@gnu=2Eorg> wrote:
>> Date: Thu, 12 Jun 2025 13:58:51 +0000
>> From: Pip Cet <pipcet@protonmail=2Ecom>
>> Cc: Eli Zaretskii <eliz@gnu=2Eorg>, 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 16:43:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 12:43:30 2025
Received: from localhost ([127.0.0.1]:59826 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPl1V-00068u-Kc
	for submit <at> 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 <eliz@HIDDEN>) id 1uPl1T-00068X-1t
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87ikl1ym6m.fsf@HIDDEN> (message from Pip Cet on Thu, 12
 Jun 2025 16:11:35 +0000)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <m1msadowmw.fsf@HIDDEN> <87ikl1ym6m.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, dancol@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Thu, 12 Jun 2025 16:11:35 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, 78737 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 16:32:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 12:32:40 2025
Received: from localhost ([127.0.0.1]:59749 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPkr1-0005Pj-F1
	for submit <at> 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 <eliz@HIDDEN>) id 1uPkqy-0005PN-5P
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87sek5ysbs.fsf@HIDDEN> (message from Pip Cet on Thu, 12
 Jun 2025 13:58:51 +0000)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, dancol@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Thu, 12 Jun 2025 13:58:51 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, 78737 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 16:11:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 12:11:53 2025
Received: from localhost ([127.0.0.1]:59657 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPkWu-00041E-GY
	for submit <at> 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 <pipcet@HIDDEN>)
 id 1uPkWq-00040b-JH
 for 78737 <at> 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
To: Daniel Colascione <dancol@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Message-ID: <87ikl1ym6m.fsf@HIDDEN>
In-Reply-To: <m1msadowmw.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN> <87sek5ysbs.fsf@HIDDEN>
 <m1msadowmw.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

1"Daniel Colascione" <dancol@HIDDEN> writes:

> Pip Cet <pipcet@HIDDEN> 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<optimized =
out>) at keyboard.c:12400
#3  0x000055555570cfca in deliver_process_signal (sig=3D2, handler=3D0x5555=
556eab10 <handle_interrupt_signal>) at sysdep.c:1751
#4  0x00007ffff5adaed0 in <signal handler called> () 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 14:36:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 10:36:29 2025
Received: from localhost ([127.0.0.1]:59191 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPj2b-0005uJ-68
	for submit <at> 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 <dancol@HIDDEN>) id 1uPj2B-0005tE-TW
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPj0g-00BltU-1v;
 Thu, 12 Jun 2025 10:34:30 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <87sek5ysbs.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN>
 <87sek5ysbs.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Thu, 12 Jun 2025 07:35:51 -0700
Message-ID: <m1msadowmw.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Pip Cet <pipcet@HIDDEN> writes:

> "Daniel Colascione" <dancol@HIDDEN> writes:
>
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>
>>>> From: Daniel Colascione <dancol@HIDDEN>
>>>> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 13:59:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 09:59:09 2025
Received: from localhost ([127.0.0.1]:59034 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPiSS-0003K5-L2
	for submit <at> 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 <pipcet@HIDDEN>)
 id 1uPiSM-0003JO-0q
 for 78737 <at> 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
To: Daniel Colascione <dancol@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Message-ID: <87sek5ysbs.fsf@HIDDEN>
In-Reply-To: <m1bjqus4un.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN> <86v7p2gxlv.fsf@HIDDEN>
 <m1bjqus4un.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Daniel Colascione" <dancol@HIDDEN> writes:

> Eli Zaretskii <eliz@HIDDEN> writes:
>
>>> From: Daniel Colascione <dancol@HIDDEN>
>>> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737@HIDDEN=
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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 13:29:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 09:29:29 2025
Received: from localhost ([127.0.0.1]:57436 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPhzk-00017L-Sn
	for submit <at> 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 <dancol@HIDDEN>) id 1uPhzi-000176-0S
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPhyC-00BlRJ-1x;
 Thu, 12 Jun 2025 09:27:52 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86frg5h6v1.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN>
 <86plfagtgw.fsf@HIDDEN> <m1o6uuqlqz.fsf@HIDDEN>
 <86o6uugk4j.fsf@HIDDEN> <m1frg6q7fq.fsf@HIDDEN>
 <86frg5h6v1.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Thu, 12 Jun 2025 06:29:13 -0700
Message-ID: <m1y0txozpy.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Daniel Colascione <dancol@HIDDEN>
>> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 05:22:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 01:22:27 2025
Received: from localhost ([127.0.0.1]:55132 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPaOQ-0006tz-Lf
	for submit <at> 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 <eliz@HIDDEN>) id 1uPaON-0006tc-MK
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <m1frg6q7fq.fsf@HIDDEN> (message from Daniel Colascione on
 Wed, 11 Jun 2025 14:44:57 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN>
 <86plfagtgw.fsf@HIDDEN> <m1o6uuqlqz.fsf@HIDDEN>
 <86o6uugk4j.fsf@HIDDEN> <m1frg6q7fq.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Daniel Colascione <dancol@HIDDEN>
> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737 <at> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 12 Jun 2025 01:03:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 21:03:38 2025
Received: from localhost ([127.0.0.1]:54155 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPWLy-0003Dd-4p
	for submit <at> 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 <owinebar@HIDDEN>)
 id 1uPWLv-0003DI-Lj
 for 78737 <at> 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 <at> 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: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN> <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN>
 <m1sek6v4ci.fsf@HIDDEN> <86frg6e6uj.fsf@HIDDEN>
 <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN> <86plfagtgw.fsf@HIDDEN>
 <m1o6uuqlqz.fsf@HIDDEN>
In-Reply-To: <m1o6uuqlqz.fsf@HIDDEN>
From: Lynn Winebarger <owinebar@HIDDEN>
Date: Wed, 11 Jun 2025 21:03:17 -0400
X-Gm-Features: AX0GCFv_myLz5HqskkeQAeDOEC0fo3Da5W9yxvZ1-iIoL1bgyEZbibRdnxIzNAs
Message-ID: <CAM=F=bAb-vED_0EN_Cny5kPrw56n+26yf9bvh3jF91Z2SuFY4g@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
To: Daniel Colascione <dancol@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, pipcet@HIDDEN,
 monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On Wed, Jun 11, 2025 at 12:37=E2=80=AFPM Daniel Colascione <dancol@HIDDEN=
rg> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 21:45:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 17:45:15 2025
Received: from localhost ([127.0.0.1]:52613 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPTFy-0007Vg-Un
	for submit <at> 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 <dancol@HIDDEN>) id 1uPTFw-0007TA-7Y
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPTEP-00BiJc-1t;
 Wed, 11 Jun 2025 17:43:37 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86o6uugk4j.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN>
 <86plfagtgw.fsf@HIDDEN> <m1o6uuqlqz.fsf@HIDDEN>
 <86o6uugk4j.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Wed, 11 Jun 2025 14:44:57 -0700
Message-ID: <m1frg6q7fq.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Daniel Colascione <dancol@HIDDEN>
>> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737 <at> debbugs.gnu.org
>> Date: Wed, 11 Jun 2025 09:35:48 -0700
>> 
>> Eli Zaretskii <eliz@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 19:21:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 15:21:14 2025
Received: from localhost ([127.0.0.1]:51730 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPR0c-0004Xn-68
	for submit <at> 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 <eliz@HIDDEN>) id 1uPR0Z-0004XY-LO
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <m1o6uuqlqz.fsf@HIDDEN> (message from Daniel Colascione on
 Wed, 11 Jun 2025 09:35:48 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN>
 <86plfagtgw.fsf@HIDDEN> <m1o6uuqlqz.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Daniel Colascione <dancol@HIDDEN>
> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737 <at> debbugs.gnu.org
> Date: Wed, 11 Jun 2025 09:35:48 -0700
> 
> Eli Zaretskii <eliz@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 16:36:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 12:36:14 2025
Received: from localhost ([127.0.0.1]:50772 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPOQs-0005pj-LU
	for submit <at> 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 <dancol@HIDDEN>) id 1uPOQg-0005nH-RB
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPOPE-00Bh5q-2E;
 Wed, 11 Jun 2025 12:34:28 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86plfagtgw.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN>
 <86plfagtgw.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Wed, 11 Jun 2025 09:35:48 -0700
Message-ID: <m1o6uuqlqz.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Daniel Colascione <dancol@HIDDEN>
>> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737 <at> debbugs.gnu.org
>> Date: Wed, 11 Jun 2025 07:57:52 -0700
>> 
>> Eli Zaretskii <eliz@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 15:59:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 11:59:26 2025
Received: from localhost ([127.0.0.1]:50522 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPNrJ-0002QL-2W
	for submit <at> 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 <eliz@HIDDEN>) id 1uPNrF-0002Pq-DB
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <m1bjqus4un.fsf@HIDDEN> (message from Daniel Colascione on
 Wed, 11 Jun 2025 07:57:52 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN> <m1bjqus4un.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Daniel Colascione <dancol@HIDDEN>
> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737 <at> debbugs.gnu.org
> Date: Wed, 11 Jun 2025 07:57:52 -0700
> 
> Eli Zaretskii <eliz@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 15:38:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 11:38:48 2025
Received: from localhost ([127.0.0.1]:50382 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPNXL-0000YK-4o
	for submit <at> 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 <dancol@HIDDEN>) id 1uPNXF-0000Xr-5N
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPNVi-00BgU8-39;
 Wed, 11 Jun 2025 11:37:06 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <875xh21f2w.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <875xh21f2w.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Wed, 11 Jun 2025 08:38:26 -0700
Message-ID: <m15xh2s2z1.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Pip Cet <pipcet@HIDDEN> writes:

> "Daniel Colascione" <dancol@HIDDEN> writes:
>
>> Eli Zaretskii <eliz@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 15:19:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 11:19:23 2025
Received: from localhost ([127.0.0.1]:50237 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPNEY-0004Oa-US
	for submit <at> 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 <pipcet@HIDDEN>)
 id 1uPNEV-0004OE-QL
 for 78737 <at> 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
To: Daniel Colascione <dancol@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Message-ID: <875xh21f2w.fsf@HIDDEN>
In-Reply-To: <m1ikl2tloy.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Daniel Colascione" <dancol@HIDDEN> writes:

> Eli Zaretskii <eliz@HIDDEN> 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 14:58:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 10:58:05 2025
Received: from localhost ([127.0.0.1]:50051 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPMtw-0002OO-A6
	for submit <at> 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 <dancol@HIDDEN>) id 1uPMtt-0002Np-Dy
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPMsS-00BgDg-3A;
 Wed, 11 Jun 2025 10:56:32 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86v7p2gxlv.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
 <86v7p2gxlv.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Wed, 11 Jun 2025 07:57:52 -0700
Message-ID: <m1bjqus4un.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Daniel Colascione <dancol@HIDDEN>
>> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 14:49:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 10:49:34 2025
Received: from localhost ([127.0.0.1]:49967 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPMlh-0001cv-Hs
	for submit <at> 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 <dancol@HIDDEN>) id 1uPMle-0001cj-Od
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPMkF-00Bft6-1w;
 Wed, 11 Jun 2025 10:48:03 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <87bjqu1ho9.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <87bjqu1ho9.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Wed, 11 Jun 2025 07:49:23 -0700
Message-ID: <m1msaes58s.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Pip Cet <pipcet@HIDDEN> writes:

> "Daniel Colascione" <dancol@HIDDEN> writes:
>
>> Pip Cet <pipcet@HIDDEN> writes:
>>
>>> "Daniel Colascione" <dancol@HIDDEN> writes:
>>>
>>>> On June 10, 2025 10:40:39 AM PDT, Pip Cet <pipcet@HIDDEN> wrote:
>>>>>"Stefan Monnier" <monnier@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 14:30:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 10:30:03 2025
Received: from localhost ([127.0.0.1]:49797 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPMSo-0008Lp-2Z
	for submit <at> 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 <eliz@HIDDEN>) id 1uPMSk-0008Ku-HP
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <m1ikl2tloy.fsf@HIDDEN> (message from Daniel Colascione on
 Wed, 11 Jun 2025 07:08:45 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN> <m1ikl2tloy.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Daniel Colascione <dancol@HIDDEN>
> Cc: pipcet@HIDDEN,  monnier@HIDDEN,  78737 <at> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 14:23:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 10:23:27 2025
Received: from localhost ([127.0.0.1]:49732 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPMMO-0007pJ-K8
	for submit <at> 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 <pipcet@HIDDEN>)
 id 1uPMMK-0007ni-6N
 for 78737 <at> 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
To: Daniel Colascione <dancol@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Message-ID: <87bjqu1ho9.fsf@HIDDEN>
In-Reply-To: <m1sek6v4ci.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN> <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Daniel Colascione" <dancol@HIDDEN> writes:

> Pip Cet <pipcet@HIDDEN> writes:
>
>> "Daniel Colascione" <dancol@HIDDEN> writes:
>>
>>> On June 10, 2025 10:40:39 AM PDT, Pip Cet <pipcet@HIDDEN> wrote=
:
>>>>"Stefan Monnier" <monnier@HIDDEN> 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 14:09:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 10:09:07 2025
Received: from localhost ([127.0.0.1]:49632 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPM8U-0006hr-E4
	for submit <at> 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 <dancol@HIDDEN>) id 1uPM8O-0006gR-Uj
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPM6v-00BeqH-24;
 Wed, 11 Jun 2025 10:07:25 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86frg6e6uj.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
 <86frg6e6uj.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Wed, 11 Jun 2025 07:08:45 -0700
Message-ID: <m1ikl2tloy.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Daniel Colascione <dancol@HIDDEN>
>> Cc: Stefan Monnier <monnier@HIDDEN>,  Eli Zaretskii
>>  <eliz@HIDDEN>,  78737 <at> debbugs.gnu.org
>> Date: Wed, 11 Jun 2025 05:40:29 -0700
>> 
>> Pip Cet <pipcet@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 13:38:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 09:38:41 2025
Received: from localhost ([127.0.0.1]:48502 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPLf7-0000yT-0j
	for submit <at> 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 <eliz@HIDDEN>) id 1uPLf3-0000xv-Ch
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <m1sek6v4ci.fsf@HIDDEN> (message from Daniel Colascione on
 Wed, 11 Jun 2025 05:40:29 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN> <m1sek6v4ci.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Daniel Colascione <dancol@HIDDEN>
> Cc: Stefan Monnier <monnier@HIDDEN>,  Eli Zaretskii
>  <eliz@HIDDEN>,  78737 <at> debbugs.gnu.org
> Date: Wed, 11 Jun 2025 05:40:29 -0700
> 
> Pip Cet <pipcet@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 13:24:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 09:24:21 2025
Received: from localhost ([127.0.0.1]:48383 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPLRF-00089J-0F
	for submit <at> 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 <eliz@HIDDEN>) id 1uPLRA-00088s-UO
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: dancol@HIDDEN, Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Tue, 10 Jun 2025 13:23:29 -0400)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>,  pipcet@HIDDEN,
>   78737 <at> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 12:40:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 08:40:47 2025
Received: from localhost ([127.0.0.1]:48069 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPKl4-0004FQ-Oe
	for submit <at> 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 <dancol@HIDDEN>) id 1uPKl1-0004F1-0J
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPKjV-00BdVF-0o;
 Wed, 11 Jun 2025 08:39:09 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <87h60m1sdg.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
 <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
 <87h60m1sdg.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Wed, 11 Jun 2025 05:40:29 -0700
Message-ID: <m1sek6v4ci.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Pip Cet <pipcet@HIDDEN> writes:

> "Daniel Colascione" <dancol@HIDDEN> writes:
>
>> On June 10, 2025 10:40:39 AM PDT, Pip Cet <pipcet@HIDDEN> wrote:
>>>"Stefan Monnier" <monnier@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 10:32:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jun 11 06:32:18 2025
Received: from localhost ([127.0.0.1]:47207 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPIkj-0007oq-Oz
	for submit <at> 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 <pipcet@HIDDEN>)
 id 1uPIkg-0007o9-2L
 for 78737 <at> 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
To: Daniel Colascione <dancol@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Message-ID: <87h60m1sdg.fsf@HIDDEN>
In-Reply-To: <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN> <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <87msaf1omo.fsf@HIDDEN>
 <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Daniel Colascione" <dancol@HIDDEN> writes:

> On June 10, 2025 10:40:39 AM PDT, Pip Cet <pipcet@HIDDEN> wrote:
>>"Stefan Monnier" <monnier@HIDDEN> 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 11 Jun 2025 02:57:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 22:57:00 2025
Received: from localhost ([127.0.0.1]:44046 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uPBe7-0003rv-NR
	for submit <at> 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 <dancol@HIDDEN>) id 1uPBe0-0003rV-59
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uPBcf-00Bavn-20;
 Tue, 10 Jun 2025 22:55:29 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <m1ecvr8k6t.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <m1ecvr8k6t.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Tue, 10 Jun 2025 19:56:49 -0700
Message-ID: <m134c7vvda.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Daniel Colascione <dancol@HIDDEN> writes:

> Stefan Monnier <monnier@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 20:46:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 16:46:18 2025
Received: from localhost ([127.0.0.1]:41718 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uP5rN-0003t6-QW
	for submit <at> 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 <dancol@HIDDEN>) id 1uP5rK-0003su-CC
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uP5pv-00BZr0-0h;
 Tue, 10 Jun 2025 16:44:47 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Stephen Berman <stephen.berman@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <87wm9jmj5p.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <m1ecvr8k6t.fsf@HIDDEN>
 <87wm9jmj5p.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Tue, 10 Jun 2025 13:46:06 -0700
Message-ID: <m17c1jz5o1.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Stephen Berman <stephen.berman@HIDDEN> writes:

> On Tue, 10 Jun 2025 12:34:34 -0700 Daniel Colascione <dancol@HIDDEN> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 20:33:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 16:33:18 2025
Received: from localhost ([127.0.0.1]:41467 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uP5eo-0002oF-3s
	for submit <at> 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 <stephen.berman@HIDDEN>)
 id 1uP5em-0002nz-8D
 for 78737 <at> 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@HIDDEN;
 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 <stephen.berman@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <m1ecvr8k6t.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <m1ecvr8k6t.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
Date: Tue, 10 Jun 2025 22:33:06 +0200
Message-ID: <87wm9jmj5p.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

On Tue, 10 Jun 2025 12:34:34 -0700 Daniel Colascione <dancol@HIDDEN> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 19:46:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 15:46:40 2025
Received: from localhost ([127.0.0.1]:40335 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uP4vf-0007Ah-A6
	for submit <at> 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 <dancol@HIDDEN>) id 1uP4vZ-0007AP-TZ
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uP4u3-00BZEz-0i;
 Tue, 10 Jun 2025 15:44:59 -0400
Date: Tue, 10 Jun 2025 12:46:19 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <87msaf1omo.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN> <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN> <87msaf1omo.fsf@HIDDEN>
Message-ID: <6DD09442-EDD3-411F-8F90-5145612AE177@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



On June 10, 2025 10:40:39 AM PDT, Pip Cet <pipcet@protonmail=2Ecom> wrote:
>"Stefan Monnier" <monnier@iro=2Eumontreal=2Eca> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 19:35:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 15:35:00 2025
Received: from localhost ([127.0.0.1]:39991 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uP4kK-00060I-BA
	for submit <at> 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 <dancol@HIDDEN>) id 1uP4kE-0005z6-Bn
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uP4ih-00BZ4y-1b;
 Tue, 10 Jun 2025 15:33:15 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Tue, 10 Jun 2025 12:34:34 -0700
Message-ID: <m1ecvr8k6t.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Stefan Monnier <monnier@HIDDEN> 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?)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 17:40:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 13:40:56 2025
Received: from localhost ([127.0.0.1]:39463 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uP2xy-0004nN-Pp
	for submit <at> 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 <pipcet@HIDDEN>)
 id 1uP2xu-0004lM-J5
 for 78737 <at> 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
To: Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Message-ID: <87msaf1omo.fsf@HIDDEN>
In-Reply-To: <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN> <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
 <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
 Daniel Colascione <dancol@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Stefan Monnier" <monnier@HIDDEN> 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 17:23:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 13:23:53 2025
Received: from localhost ([127.0.0.1]:39419 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uP2hT-0001bF-48
	for submit <at> 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 <monnier@HIDDEN>)
 id 1uP2hP-0001Zd-4a
 for 78737 <at> 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 <monnier@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
Message-ID: <jwvy0tzikei.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
 <8634c7fv4p.fsf@HIDDEN>
 <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 16:22:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 12:22:16 2025
Received: from localhost ([127.0.0.1]:39302 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uP1jo-0006nP-94
	for submit <at> 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 <dancol@HIDDEN>) id 1uP1jh-0006mE-Vc
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uP1iJ-00BY2c-1c;
 Tue, 10 Jun 2025 12:20:39 -0400
Date: Tue, 10 Jun 2025 09:21:56 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <8634c7fv4p.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN> <8634c7fv4p.fsf@HIDDEN>
Message-ID: <24893AF1-FB95-4003-81DB-8D4327FD3490@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



On June 10, 2025 8:56:22 AM PDT, Eli Zaretskii <eliz@gnu=2Eorg> wrote:
>> Date: Tue, 10 Jun 2025 08:06:46 -0700
>> From: Daniel Colascione <dancol@dancol=2Eorg>
>> 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




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 15:56:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 11:56:36 2025
Received: from localhost ([127.0.0.1]:39265 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uP1L0-0002Gt-E6
	for submit <at> 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 <eliz@HIDDEN>) id 1uP1Kx-0002FN-I1
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN> (message from
 Daniel Colascione on Tue, 10 Jun 2025 08:06:46 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
 <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Tue, 10 Jun 2025 08:06:46 -0700
> From: Daniel Colascione <dancol@HIDDEN>
> CC: pipcet@HIDDEN, 78737 <at> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 15:07:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 11:07:04 2025
Received: from localhost ([127.0.0.1]:39152 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uP0Z4-0001YS-2E
	for submit <at> 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 <dancol@HIDDEN>) id 1uP0Z0-0001Xg-HR
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uP0XX-00BXkb-1h;
 Tue, 10 Jun 2025 11:05:27 -0400
Date: Tue, 10 Jun 2025 08:06:46 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Stefan Monnier <monnier@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
User-Agent: K-9 Mail for Android
In-Reply-To: <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
 <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
Message-ID: <D156E2B3-327D-46CF-AE9D-E791B6065341@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)



On June 10, 2025 4:22:38 AM PDT, Stefan Monnier <monnier@iro=2Eumontreal=
=2Eca> 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






Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 11:22:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 07:22:57 2025
Received: from localhost ([127.0.0.1]:35776 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uOx4D-0005BB-8R
	for submit <at> 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 <monnier@HIDDEN>)
 id 1uOx4A-0005At-K0
 for 78737 <at> 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 <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <86jz5jg8p1.fsf@HIDDEN>
Message-ID: <jwvzfefluke.fsf-monnier+emacs@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN> <86jz5jg8p1.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN,
 Daniel Colascione <dancol@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 11:03:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 07:03:56 2025
Received: from localhost ([127.0.0.1]:35438 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uOwln-0003j0-WE
	for submit <at> 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 <eliz@HIDDEN>) id 1uOwlk-0003iV-RJ
 for 78737 <at> 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 <eliz@HIDDEN>)
 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@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>,
 Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <m1sek87xh9.fsf@HIDDEN> (message from Daniel Colascione on
 Tue, 10 Jun 2025 02:32:50 -0700)
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
 <m1sek87xh9.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 78737 <at> debbugs.gnu.org
> From: Daniel Colascione <dancol@HIDDEN>
> Date: Tue, 10 Jun 2025 02:32:50 -0700
> 
> Pip Cet <pipcet@HIDDEN> writes:
> 
> > "Daniel Colascione" <dancol@HIDDEN> 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?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 09:33:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 05:33:01 2025
Received: from localhost ([127.0.0.1]:34507 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uOvLn-0000ae-Ax
	for submit <at> 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 <dancol@HIDDEN>) id 1uOvLh-0000ZV-Gh
 for 78737 <at> 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 <dancol@HIDDEN>) id 1uOvKN-00BWvY-15;
 Tue, 10 Jun 2025 05:31:31 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
In-Reply-To: <87ikl42c4l.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN> <87ikl42c4l.fsf@HIDDEN>
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Tue, 10 Jun 2025 02:32:50 -0700
Message-ID: <m1sek87xh9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Pip Cet <pipcet@HIDDEN> writes:

> "Daniel Colascione" <dancol@HIDDEN> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at 78737 <at> debbugs.gnu.org:


Received: (at 78737) by debbugs.gnu.org; 10 Jun 2025 09:13:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jun 10 05:13:27 2025
Received: from localhost ([127.0.0.1]:34396 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uOv2s-0006Au-IF
	for submit <at> 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 <pipcet@HIDDEN>)
 id 1uOv2j-00069m-Gd
 for 78737 <at> 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
To: Daniel Colascione <dancol@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Message-ID: <87ikl42c4l.fsf@HIDDEN>
In-Reply-To: <m1ikl4iqtg.fsf@HIDDEN>
References: <m1ikl4iqtg.fsf@HIDDEN>
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-Debbugs-Envelope-To: 78737
Cc: 78737 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

"Daniel Colascione" <dancol@HIDDEN> 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





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 9 Jun 2025 20:49:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jun 09 16:49:26 2025
Received: from localhost ([127.0.0.1]:58095 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1uOjQr-00011r-Ot
	for submit <at> 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 <dancol@HIDDEN>) id 1uOjQp-0000yY-Bh
 for submit <at> 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 <dancol@HIDDEN>) id 1uOjQY-0003XT-Me
 for bug-gnu-emacs@HIDDEN; 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 <dancol@HIDDEN>) id 1uOjQW-0003YV-Ky
 for bug-gnu-emacs@HIDDEN; 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 <dancol@HIDDEN>) id 1uOjPB-00BSim-1D
 for bug-gnu-emacs@HIDDEN; Mon, 09 Jun 2025 16:47:41 -0400
From: Daniel Colascione <dancol@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: sit-for behavior changes when byte-compiled
User-Agent: mu4e 1.12.10; emacs 31.0.50
Date: Mon, 09 Jun 2025 13:48:59 -0700
Message-ID: <m1ikl4iqtg.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=2600:3c01:e000:3d8::1;
 envelope-from=dancol@HIDDEN; helo=dancol.org
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
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?




Acknowledgement sent to Daniel Colascione <dancol@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#78737; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Fri, 13 Jun 2025 15:15:06 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.