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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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 :-(.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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?
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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 <<a hre=
f=3D"mailto:eliz@HIDDEN" target=3D"_blank" rel=3D"noreferrer">eliz@HIDDEN=
</a>> 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">=
> From: Daniel Colascione <<a href=3D"mailto:dancol@HIDDEN" rel=
=3D"noreferrer noreferrer" target=3D"_blank">dancol@HIDDEN</a>><br>
> Cc: Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" rel=3D"noreferre=
r noreferrer" target=3D"_blank">eliz@HIDDEN</a>>,=C2=A0 <a href=3D"mail=
to:monnier@HIDDEN" rel=3D"noreferrer noreferrer" target=3D"_blank=
">monnier@HIDDEN</a>,<br>
>=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>
> Date: Thu, 12 Jun 2025 11:48:50 -0700<br>
> <br>
> Pip Cet <<a href=3D"mailto:pipcet@HIDDEN" rel=3D"noreferrer=
noreferrer" target=3D"_blank">pipcet@HIDDEN</a>> writes:<br>
> <br>
> > I'd like read-event, when called while inhibit-quit is t, to =
report<br>
> > quits by setting quit-flag in addition to returning quit_char: it=
'll<br>
> > simplify the C code, and it would make<br>
> ><br>
> > (while t<br>
> >=C2=A0 =C2=A0(let ((inhibit-quit t))<br>
> >=C2=A0 =C2=A0 =C2=A0(read-event)))<br>
> <br>
> I strongly disagree.=C2=A0 read-event should read an event.<br>
> Setting quit-flag by side effect when it happens to read one key and n=
ot<br>
> 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'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 "in quick succession" set quit-flag,=
IOW<br>
=C2=A0 =C2=A0"C-g C-g" 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 "interrupts"?=C2=A0 The key strokes =
would be processed by C machinery and never seen directly by lisp code and =
not be considered "events".</div><div dir=3D"auto">Then C-g could=
be bound to a thunk signalling quit, and the effect of "inhibit-quit&=
quot; achieved by removing C-g from the list in a given dynamic scope.=C2=
=A0 Then user code could make other key-strokes "special" without=
resorting to read-event.=C2=A0 For example, this read-event call in term.e=
l:</div><div dir=3D"auto">(message "Hit space to flush")</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--
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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?
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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?
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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?
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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?
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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?
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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?
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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?)
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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?
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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?
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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.
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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
bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.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?
Daniel Colascione <dancol@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#78737; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.