Received: (at 79661) by debbugs.gnu.org; 22 Oct 2025 11:22:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 22 07:22:55 2025
Received: from localhost ([127.0.0.1]:55649 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBWve-0005Qt-Nh
for submit <at> debbugs.gnu.org; Wed, 22 Oct 2025 07:22:55 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:43918)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vBWvb-0005Qc-Ek
for 79661 <at> debbugs.gnu.org; Wed, 22 Oct 2025 07:22:52 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vBWvV-0000sj-9T; Wed, 22 Oct 2025 07:22:45 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=9iaTTUi1kXCUftaHqwviMy5D9mJBFX8itKDKsEzTngc=; b=SF3JHAAN3KoH
Q8VXcqurvKa40i24E6AdUjO5v9nzAxrcN6t5pfznJu821z0ADpJeWgc4/DQKuXyGB4QhiW9JoN8Sz
mW+B6lnzseuYeCY0+fdkEmBVKwyvmczmGOOqF08tA4V6Hnv0/iSOLAddoLmx89R1Io/HEuDBR9h9f
l3pGaMwHAyV/3l9i//PBwEyhdLSs4LdX1ocdlsZbjw5h3eUmgTgd+sKdK6skWAwdQy7EDfjAV7ieV
Z+/sGFohkkxNdExZA43sGdWFpzhMZpPE2vcV2Oil51SIeJTDKF/VFFbbga0LXKEgAQ6FweAN2YRfX
ZweeG9Dmf30YrprXIfv1gA==;
Date: Wed, 22 Oct 2025 14:22:41 +0300
Message-Id: <86wm4nuqny.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <875xc8t138.fsf@HIDDEN> (message from Pip Cet on Tue, 21
Oct 2025 21:10:02 +0000)
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86plagwe98.fsf@HIDDEN> <jwva51kjqnf.fsf-monnier+emacs@HIDDEN>
<86ldl4wcjr.fsf@HIDDEN> <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN>
<87sefct8rv.fsf@HIDDEN> <jwvikg8gk4z.fsf-monnier+emacs@HIDDEN>
<87h5vst51j.fsf@HIDDEN> <jwv7bwoggcm.fsf-monnier+emacs@HIDDEN>
<875xc8t138.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79661
Cc: n142857@HIDDEN, monnier@HIDDEN, 79661 <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: -3.3 (---)
> Date: Tue, 21 Oct 2025 21:10:02 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, n142857@HIDDEN, 79661 <at> debbugs.gnu.org
>
> "Stefan Monnier" <monnier@HIDDEN> writes:
>
> >>> One of the reasons why I disagree is that my test of your
> >>> `unblock_input_to` patch suggests strongly that it fixes not only the
> >>> problem that we sometimes discard input (because the throw is turned
> >>> into a `quit`) but also the problem that we sometimes keep waiting the
> >>> full `sleep-for` even after a key was pressed.
> >>
> >> Hmm. Are we sure that isn't a timer thing?
> >
> > Hmm... while I had had the impression that the `sleep-for` was "always"
> > interrupted right away (with the `unblock_input_to` patch), I can't
> > reproduce it now. So it seems I was confused.
>
> Easy enough to fix, see patch series at the end of this email.
> [...]
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5403,6 +5403,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
> else if (pending_signals)
> process_pending_signals ();
>
> + /* Handle throw-on-input even in sleep-for. */
> + if (!NILP (Vquit_flag) && EQ (Vthrow_on_input, Vquit_flag))
> + maybe_quit ();
Please _never_ make changes in wait_reading_process_output that have
such wide effects. That function supports two very different uses:
(a) waiting for user or user-related input, and (b) waiting for
subprocesses to produce some output. These two should never be
affected together without a very good reason.
So, if we decide to install something like that, please only do that
in the case that affects sleep-for, and does not affect waiting for
subprocesses.
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -2446,7 +2446,8 @@ #define MAX_ENCODED_BYTES 16
> coding->dst_bytes = sizeof dest;
> decode_coding_c_string (coding, src, n, Qnil);
> eassert (coding->produced_char <= n);
> - if (coding->produced_char == 0)
> + if (coding->produced_char == 0
> + || coding->carryover_bytes)
> { /* The encoded sequence is incomplete. */
If coding->produced_char > 0 and coding->carryover_bytes > 0, we
actually might have produced one or more characters, no? Why does it
make sense not to return anything in that case?
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 22 Oct 2025 07:40:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 22 03:40:04 2025 Received: from localhost ([127.0.0.1]:54859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vBTRy-0000os-8s for submit <at> debbugs.gnu.org; Wed, 22 Oct 2025 03:40:03 -0400 Received: from mail-10628.protonmail.ch ([79.135.106.28]:58307) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vBTRo-0000oF-3p for 79661 <at> debbugs.gnu.org; Wed, 22 Oct 2025 03:39:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1761118784; x=1761377984; bh=ZSzvZ0rOOU1rH57doNp/tlqbOM+IYZoknqzjstG5aS0=; 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; b=CYDgHnhNE7X5OzKAujNlv6mI3CiZDnh37nOjz9t4uPT/TiPAX+qxCokRAyUUviiXD uysL/6nYXcSuMKYDKMW0DffMX4n67MwtrA//ayIIj6/JXJnUZrbv4/wZuOzuk9Qmso qnqxL9dwwpMQO8kmuyGz3rae41ODujsRtFXqU8dPwTxv6yfC2wj/za2fRmjywghYsQ fbHQZG6yVwhQHHKpXf+NXFEf3+QqvySv+6gNBuKAG2x3jjloBBq7Mrdzme5AS0og+H wtxUtACGnqYsjm/eBQNzWqTJQlj6xveOTH+WbQJcd3NS+UC0kiaIKFP+RXvAcFj8mh 2nZ6kvUfO+T9g== Date: Wed, 22 Oct 2025 07:39:37 +0000 To: Stefan Monnier <monnier@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY Message-ID: <87wm4ns7y0.fsf@HIDDEN> In-Reply-To: <jwvh5vseyo5.fsf-monnier+emacs@HIDDEN> References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86ldl4wcjr.fsf@HIDDEN> <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN> <87sefct8rv.fsf@HIDDEN> <jwvikg8gk4z.fsf-monnier+emacs@HIDDEN> <87h5vst51j.fsf@HIDDEN> <jwv7bwoggcm.fsf-monnier+emacs@HIDDEN> <875xc8t138.fsf@HIDDEN> <jwvh5vseyo5.fsf-monnier+emacs@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 331e78d26d7a8d3b2367080831e45ca474b98283 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: 79661 Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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 (-) "Stefan Monnier" <monnier@HIDDEN> writes: >>>> And we definitely need the memq_no_signal change because the original >>>> bug, with a 3-byte UTF-8 character sent in a single syscall, manifests >>>> there at least some of the time. >>> I have no idea about that because I don't understand how it relates. >> It's the original bug that was reported, AFAICT. The double-throw bug >> is different. >> >>> Can you still turn a throw-on-input into a quit that discards some byte= s >>> after applying just my `throw-on-input` patch? >> >> If I follow the original recipe, Emacs still discards the third byte. >> The memq_no_signal thing is needed, too, at least on this system, in >> order to prevent that. However, there's no quit () in this case. > > Hmm... why does it discard any byte? AFAICT the recipe does not involve > any quit and only quit discards bytes. So I'd like to better understand > how the quit-check in `Fmemq` ends up discarding the bytes. tty_read_avail_input reads three bytes, then calls kbd_buffer_store_buffered_event on them individually. The first call to kbd_buffer_store_buffered_event sets quit-flag, but returns. The second call to kbd_buffer_store_buffered_event stores the second byte, but then calls Fmemq, which checks quit-flag and throws, exiting from tty_read_avail_input non-locally. So there's no third call, but the byte has already been read (but not stored) and is now lost. >> From b9b75fb235561ca83f188755c3706405ab6669a2 Mon Sep 17 00:00:00 2001 >> From: Pip Cet <pipcet@HIDDEN> >> Date: Tue, 21 Oct 2025 20:02:11 +0000 >> Subject: [PATCH 2/6] Avoid quits in keyboard_store_buffered_event (bug#7= 9661) >> >> * src/fns.c (memq_no_signal): New function. >> * src/keyboard.c (is_ignored_event): Use it instead of 'Fmemq'. > > Not opposed, but I'd like to have a clearer explanation why it's needed Agreed. > (and why it's needed only in `is_ignored_event`). I don't fully understand where quits are permitted and where they aren't in keyboard.c. Consider apply_modifiers: it calls assq_no_quit, which suggests it shouldn't quit, but then it calls Fput, which can quit. Maybe the assq_no_quit is used for performance reasons alone? read_decoded_event_from_main_queue -> read_event_from_main_queue -> kbd_buffer_get_event ->=C2=A0make_lispy_event -> apply_modifiers probably shouldn't quit, but as you can see by the length of that call chain, checking every single quitting call in keyboard.c is a tedious task. So I haven't done that. My suggestion is a "when in doubt, don't quit" policy for keyboard.c, complete with variants of the Lisp functions which don't quit but don't infloop on circular inputs; it should be safe to use them instead of the signaling versions, so if we do so in a case where it isn't strictly necessary, there's no harm done. >> From 60ae4c44c5b34a2f1190cadfa6d6ba05f070dcf4 Mon Sep 17 00:00:00 2001 >> From: Pip Cet <pipcet@HIDDEN> >> Date: Tue, 21 Oct 2025 20:05:24 +0000 >> Subject: [PATCH 4/6] Allow 'throw-on-input' to interrupt 'sleep-for' >> (bug#79961) >> >> * src/process.c (wait_reading_process_output): Process quit flag if >> it's a throw-on-input quit. >> --- >> src/process.c | 4 ++++ >> 1 file changed, 4 insertions(+) >> >> diff --git a/src/process.c b/src/process.c >> index 86e83e58c56..5ed70cda6a2 100644 >> --- a/src/process.c >> +++ b/src/process.c >> @@ -5403,6 +5403,10 @@ wait_reading_process_output (intmax_t time_limit,= int nsecs, int read_kbd, >> else if (pending_signals) >> =09process_pending_signals (); >> >> + /* Handle throw-on-input even in sleep-for. */ >> + if (!NILP (Vquit_flag) && EQ (Vthrow_on_input, Vquit_flag)) >> +=09maybe_quit (); >> + >> /* Exit now if the cell we're waiting for became non-nil. */ >> if (! NILP (wait_for_cell) && ! NILP (XCAR (wait_for_cell))) >> =09break; > > Why is it need for the tty case and not for the GUI case (at least in > my tests, it seems the `sleep-for` is always immediately interrupted > when run in the GUI)? Oh, I misunderstood the problem here: read_kbd is 0 in sleep_for, so we call maybe_quit in the loop, but we call it just once: maybe_quit either checks quit-flag or calls process_pending_signals, which may set quit-flag, but doesn't do both. We need to call it multiple times, until it no longer does anything. In the GUI case, I suspect there are simply enough messages being exchanged for every keypress that we go through the loop multiple times per keypress, which is sufficient in practice. > Why don't we also handle `C-g` in the same way? We can't if read_kbd =3D=3D -1, and C-g should count as an ordinary input character. However, as all we need to do is to call maybe_quit repeatedly, the special case should go away... >> From 1a04554c40b2b04d428c3d30cc36b98a85699879 Mon Sep 17 00:00:00 2001 >> From: Pip Cet <pipcet@HIDDEN> >> Date: Tue, 21 Oct 2025 20:06:49 +0000 >> Subject: [PATCH 5/6] Allow carryover bytes when decoding events (bug#799= 61) >> >> * src/keyboard.c (read_decoded_event_from_main_queue): Handle >> carryover bytes. Don't assert it cannot happen. > > LGTM > >> From 5504ad38ed14e31faed48b124823c428e2cdfa9a Mon Sep 17 00:00:00 2001 >> From: Pip Cet <pipcet@HIDDEN> >> Date: Tue, 21 Oct 2025 20:12:46 +0000 >> Subject: [PATCH 6/6] Detect invalid bytes sooner in UTF-8 decoding (bug#= 79961) >> >> * src/coding.c (UTF_8_3_OCTET_LEADING_P): New macro. >> (detect_coding_utf_8): >> (decode_coding_utf_8): Use it to detect invalid sequences. > > I'll let someone else review this code. > [ Could we have some new tests for that and the previous patch? ] I've written a test for patch 6/6, but I don't know how to test patch 5/6. Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 21:36:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 17:36:19 2025
Received: from localhost ([127.0.0.1]:53579 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBK1j-0003mD-6c
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 17:36:19 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49948)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBK1g-0003lm-1M
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 17:36:17 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1894281626;
Tue, 21 Oct 2025 17:36:10 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761082567;
bh=BAxdoMnMrUDQHdb4K02mX1Hl+VWsFh06hbtkutSLHhc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=GwlOYrqhExIfGwuBQnvMf4HGyw6lRc6eO2aB0Z0k6Vyc9zjkJbf3DC3Qrzsz6pPJA
+1K7KO8KCgyrqfJbOb8bAxBrn/LO7zuVcSnhDYS4c6sh/KZXx2xmNBAecJRGpeDrrl
Zul09WiSoJbkSjSqRtHXlnmoMR5bUKQZS7TaLmpXslwFr7iTyqO58pYDGKS6B2NxdW
KIOsiiEdN4ufZ/KHl+zj8qIhsGH8D6MnuAoOA7fMuLJEiQ0Fl+68TgM9RG/BkwGCwm
JzsHpzRw7p2+VpDxDPCuTyzqppFbKoqZ7tJ4pJ8ctiHLJQUbLGuBoI//8n4TFToNj7
ReOmY+NVVi4zA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C95B18053B;
Tue, 21 Oct 2025 17:36:07 -0400 (EDT)
Received: from asado (unknown [138.0.104.197])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 03FAE120387;
Tue, 21 Oct 2025 17:36:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <875xc8t138.fsf@HIDDEN>
Message-ID: <jwvh5vseyo5.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86plagwe98.fsf@HIDDEN> <jwva51kjqnf.fsf-monnier+emacs@HIDDEN>
<86ldl4wcjr.fsf@HIDDEN> <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN>
<87sefct8rv.fsf@HIDDEN>
<jwvikg8gk4z.fsf-monnier+emacs@HIDDEN>
<87h5vst51j.fsf@HIDDEN>
<jwv7bwoggcm.fsf-monnier+emacs@HIDDEN>
<875xc8t138.fsf@HIDDEN>
Date: Tue, 21 Oct 2025 17:36:00 -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.388 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
KAM_LOTSOFHASH 0.25 Emails with lots of hash-like gibberish
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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: -3.3 (---)
>>> And we definitely need the memq_no_signal change because the original
>>> bug, with a 3-byte UTF-8 character sent in a single syscall, manifests
>>> there at least some of the time.
>> I have no idea about that because I don't understand how it relates.
> It's the original bug that was reported, AFAICT. The double-throw bug
> is different.
>
>> Can you still turn a throw-on-input into a quit that discards some bytes
>> after applying just my `throw-on-input` patch?
>
> If I follow the original recipe, Emacs still discards the third byte.
> The memq_no_signal thing is needed, too, at least on this system, in
> order to prevent that. However, there's no quit () in this case.
Hmm... why does it discard any byte? AFAICT the recipe does not involve
any quit and only quit discards bytes. So I'd like to better understand
how the quit-check in `Fmemq` ends up discarding the bytes.
> From 517ba9959c78d7f3b5f8ad0e77eb5f5264f30b76 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet@HIDDEN>
> Date: Tue, 21 Oct 2025 20:00:31 +0000
> Subject: [PATCH 1/6] Consume Vthrow_on_input when throwing to it (bug#79661)
>
> * src/eval.c (process_quit_flag): Clear Vthrow_on_input before
> actually throwing. This prevents another throw to the same symbol
> from the unwind handler.
LGTM.
> From b9b75fb235561ca83f188755c3706405ab6669a2 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet@HIDDEN>
> Date: Tue, 21 Oct 2025 20:02:11 +0000
> Subject: [PATCH 2/6] Avoid quits in keyboard_store_buffered_event (bug#79661)
>
> * src/fns.c (memq_no_signal): New function.
> * src/keyboard.c (is_ignored_event): Use it instead of 'Fmemq'.
Not opposed, but I'd like to have a clearer explanation why it's needed
(and why it's needed only in `is_ignored_event`).
> From 309902002cd61499fb68923f41c6c4f8bd32f74e Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet@HIDDEN>
> Date: Tue, 21 Oct 2025 20:03:54 +0000
> Subject: [PATCH 3/6] Avoid handling input in unblock_input_to (bug#79661)
>
> * src/keyboard.c (unblock_input_to): Don't do anything if changing
> from level 0 to level 0.
Tempted, but yeah, I'd leave it as a comment suggesting it might be
a good idea, in case we find further evidence (or need) for it in
the future.
> From 60ae4c44c5b34a2f1190cadfa6d6ba05f070dcf4 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet@HIDDEN>
> Date: Tue, 21 Oct 2025 20:05:24 +0000
> Subject: [PATCH 4/6] Allow 'throw-on-input' to interrupt 'sleep-for'
> (bug#79961)
>
> * src/process.c (wait_reading_process_output): Process quit flag if
> it's a throw-on-input quit.
> ---
> src/process.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/process.c b/src/process.c
> index 86e83e58c56..5ed70cda6a2 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5403,6 +5403,10 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
> else if (pending_signals)
> process_pending_signals ();
>
> + /* Handle throw-on-input even in sleep-for. */
> + if (!NILP (Vquit_flag) && EQ (Vthrow_on_input, Vquit_flag))
> + maybe_quit ();
> +
> /* Exit now if the cell we're waiting for became non-nil. */
> if (! NILP (wait_for_cell) && ! NILP (XCAR (wait_for_cell)))
> break;
Why is it need for the tty case and not for the GUI case (at least in
my tests, it seems the `sleep-for` is always immediately interrupted
when run in the GUI)? Why don't we also handle `C-g` in the same way?
> From 1a04554c40b2b04d428c3d30cc36b98a85699879 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet@HIDDEN>
> Date: Tue, 21 Oct 2025 20:06:49 +0000
> Subject: [PATCH 5/6] Allow carryover bytes when decoding events (bug#79961)
>
> * src/keyboard.c (read_decoded_event_from_main_queue): Handle
> carryover bytes. Don't assert it cannot happen.
LGTM
> From 5504ad38ed14e31faed48b124823c428e2cdfa9a Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet@HIDDEN>
> Date: Tue, 21 Oct 2025 20:12:46 +0000
> Subject: [PATCH 6/6] Detect invalid bytes sooner in UTF-8 decoding (bug#79961)
>
> * src/coding.c (UTF_8_3_OCTET_LEADING_P): New macro.
> (detect_coding_utf_8):
> (decode_coding_utf_8): Use it to detect invalid sequences.
I'll let someone else review this code.
[ Could we have some new tests for that and the previous patch? ]
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 21:10:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 17:10:21 2025
Received: from localhost ([127.0.0.1]:53513 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBJca-00021y-Pg
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 17:10:21 -0400
Received: from mail-24416.protonmail.ch ([109.224.244.16]:50737)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vBJcW-00020P-1Z
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 17:10:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1761081008; x=1761340208;
bh=rIFJ9WK9gMnitzfwdvCjZrjVkWdb+04KFRk2252r6C8=;
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;
b=m7qF+zhCVPlDLHK5FVtqixvdI95w5igAXyk9LU9nMLh3o90gYHCq2V1zWzy/UVvSS
oiRezuaHdC7EzdQQpQ1w/bUwBNYgmhyvVm6WVleLcFWzVqkJ7sMOr6jldz7W7EChyE
HwwpKxEeLXMrN1XxXqJBF+zwbfdAD0FAWj/sB1jKdORU6KD23B1zdrDgWbkKFQSAxP
affQU6cXP9M/SCcn184zqDoCG5DYTHVkcPkanqKZqc7q8hKgxRETRijgDdybPUsah7
ER/N76PwxsFjqlkXDO/n9Sse62BlnLuWVAKfjiR3S5oP2AKeqxopvAMd6DkfQWiK6d
Ke+o+F+LCHv1Q==
Date: Tue, 21 Oct 2025 21:10:02 +0000
To: Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
Message-ID: <875xc8t138.fsf@HIDDEN>
In-Reply-To: <jwv7bwoggcm.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86plagwe98.fsf@HIDDEN> <jwva51kjqnf.fsf-monnier+emacs@HIDDEN>
<86ldl4wcjr.fsf@HIDDEN> <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN>
<87sefct8rv.fsf@HIDDEN> <jwvikg8gk4z.fsf-monnier+emacs@HIDDEN>
<87h5vst51j.fsf@HIDDEN> <jwv7bwoggcm.fsf-monnier+emacs@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 1503e9bea113527f720f46ab7a2337fb5a11ceb2
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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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 (-)
"Stefan Monnier" <monnier@HIDDEN> writes:
>>> One of the reasons why I disagree is that my test of your
>>> `unblock_input_to` patch suggests strongly that it fixes not only the
>>> problem that we sometimes discard input (because the throw is turned
>>> into a `quit`) but also the problem that we sometimes keep waiting the
>>> full `sleep-for` even after a key was pressed.
>>
>> Hmm. Are we sure that isn't a timer thing?
>
> Hmm... while I had had the impression that the `sleep-for` was "always"
> interrupted right away (with the `unblock_input_to` patch), I can't
> reproduce it now. So it seems I was confused.
Easy enough to fix, see patch series at the end of this email.
>> I think that makes sense (it's an API change, but a minor one).
>
> +1
>> I'm not sure why we'd also need the unblock_input_to change, but it
>> probably wouldn't hurt.
>
> I'm tempted to stay on the conservative side and just add there
> a comment pointing to this discussion, but without actually changing
> the code.
Agreed. Will change the patch in that regard.
>> And we definitely need the memq_no_signal change because the original
>> bug, with a 3-byte UTF-8 character sent in a single syscall, manifests
>> there at least some of the time.
>
> I have no idea about that because I don't understand how it relates.
It's the original bug that was reported, AFAICT. The double-throw bug
is different.
> Can you still turn a throw-on-input into a quit that discards some bytes
> after applying just my `throw-on-input` patch?
If I follow the original recipe, Emacs still discards the third byte.
The memq_no_signal thing is needed, too, at least on this system, in
order to prevent that. However, there's no quit () in this case.
Here's the patch series as it currently stands. My understanding is you
want to drop PATCH 3/6 (and replace it with a comment). The rest fix
bugs, but might not do so in the best possible way, so more discussion
seems to be needed before they are applied. However, I'm convinced that
there really are five bugs here.
From 517ba9959c78d7f3b5f8ad0e77eb5f5264f30b76 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Tue, 21 Oct 2025 20:00:31 +0000
Subject: [PATCH 1/6] Consume Vthrow_on_input when throwing to it (bug#79661=
)
* src/eval.c (process_quit_flag): Clear Vthrow_on_input before
actually throwing. This prevents another throw to the same symbol
from the unwind handler.
---
src/eval.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/eval.c b/src/eval.c
index 0c29de9f3ad..2185cd8528c 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1857,7 +1857,10 @@ process_quit_flag (void)
if (EQ (flag, Qkill_emacs))
Fkill_emacs (Qnil, Qnil);
if (EQ (Vthrow_on_input, flag))
- Fthrow (Vthrow_on_input, Qt);
+ {
+ Vthrow_on_input =3D Qnil;
+ Fthrow (flag, Qt);
+ }
quit ();
}
=20
--=20
2.51.0
From b9b75fb235561ca83f188755c3706405ab6669a2 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Tue, 21 Oct 2025 20:02:11 +0000
Subject: [PATCH 2/6] Avoid quits in keyboard_store_buffered_event (bug#7966=
1)
* src/fns.c (memq_no_signal): New function.
* src/keyboard.c (is_ignored_event): Use it instead of 'Fmemq'.
---
src/fns.c | 14 ++++++++++++++
src/keyboard.c | 2 +-
src/lisp.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/fns.c b/src/fns.c
index 5334c9f94a8..14e3a95a269 100644
--- a/src/fns.c
+++ b/src/fns.c
@@ -1926,6 +1926,20 @@ memq_no_quit (Lisp_Object elt, Lisp_Object list)
return Qnil;
}
=20
+/* Memq but doesn't signal. Unlike memq_no_quit, this function still
+ detects circular lists; like memq_no_quit, this function does not
+ allow quits and never signals. If anything goes wrong, it returns
+ Qnil. */
+Lisp_Object
+memq_no_signal (Lisp_Object key, Lisp_Object list)
+{
+ Lisp_Object tail =3D list;
+ FOR_EACH_TAIL_SAFE (tail)
+ if (EQ (XCAR (tail), key))
+ return tail;
+ return Qnil;
+}
+
DEFUN ("memql", Fmemql, Smemql, 2, 2, 0,
doc: /* Return non-nil if ELT is an element of LIST. Comparison do=
ne with `eql'.
The value is actually the tail of LIST whose car is ELT. */)
diff --git a/src/keyboard.c b/src/keyboard.c
index a9cbd107dde..9d2a3441168 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -13298,7 +13298,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_signal (ignore_event, Vwhile_no_input_ignore_event=
s));
}
=20
static void syms_of_keyboard_for_pdumper (void);
diff --git a/src/lisp.h b/src/lisp.h
index 8da5f4f1475..3d6acc30055 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4303,6 +4303,7 @@ #define CONS_TO_INTEGER(cons, type, var)=09=09=09=09\
extern void syms_of_fns (void);
extern void mark_fns (void);
Lisp_Object memq_no_quit (Lisp_Object elt, Lisp_Object list);
+Lisp_Object memq_no_signal (Lisp_Object elt, Lisp_Object list);
=20
/* Defined in sort.c */
extern void tim_sort (Lisp_Object, Lisp_Object, Lisp_Object *, const ptrdi=
ff_t,
--=20
2.51.0
From 309902002cd61499fb68923f41c6c4f8bd32f74e Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Tue, 21 Oct 2025 20:03:54 +0000
Subject: [PATCH 3/6] Avoid handling input in unblock_input_to (bug#79661)
* src/keyboard.c (unblock_input_to): Don't do anything if changing
from level 0 to level 0.
---
src/keyboard.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/keyboard.c b/src/keyboard.c
index 9d2a3441168..81b1625304b 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -8318,6 +8318,8 @@ process_pending_signals (void)
void
unblock_input_to (int level)
{
+ if (level =3D=3D interrupt_input_blocked)
+ return;
interrupt_input_blocked =3D level;
if (level =3D=3D 0)
{
--=20
2.51.0
From 60ae4c44c5b34a2f1190cadfa6d6ba05f070dcf4 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Tue, 21 Oct 2025 20:05:24 +0000
Subject: [PATCH 4/6] Allow 'throw-on-input' to interrupt 'sleep-for'
(bug#79961)
* src/process.c (wait_reading_process_output): Process quit flag if
it's a throw-on-input quit.
---
src/process.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/process.c b/src/process.c
index 86e83e58c56..5ed70cda6a2 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5403,6 +5403,10 @@ wait_reading_process_output (intmax_t time_limit, in=
t nsecs, int read_kbd,
else if (pending_signals)
=09process_pending_signals ();
=20
+ /* Handle throw-on-input even in sleep-for. */
+ if (!NILP (Vquit_flag) && EQ (Vthrow_on_input, Vquit_flag))
+=09maybe_quit ();
+
/* Exit now if the cell we're waiting for became non-nil. */
if (! NILP (wait_for_cell) && ! NILP (XCAR (wait_for_cell)))
=09break;
--=20
2.51.0
From 1a04554c40b2b04d428c3d30cc36b98a85699879 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Tue, 21 Oct 2025 20:06:49 +0000
Subject: [PATCH 5/6] Allow carryover bytes when decoding events (bug#79961)
* src/keyboard.c (read_decoded_event_from_main_queue): Handle
carryover bytes. Don't assert it cannot happen.
---
src/keyboard.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/keyboard.c b/src/keyboard.c
index 81b1625304b..daf8b066a7a 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2446,7 +2446,8 @@ #define MAX_ENCODED_BYTES 16
=09=09 coding->dst_bytes =3D sizeof dest;
=09=09 decode_coding_c_string (coding, src, n, Qnil);
=09=09 eassert (coding->produced_char <=3D n);
-=09=09 if (coding->produced_char =3D=3D 0)
+=09=09 if (coding->produced_char =3D=3D 0
+=09=09 || coding->carryover_bytes)
=09=09 { /* The encoded sequence is incomplete. */
=09=09 if (n < MAX_ENCODED_BYTES) /* Avoid buffer overflow. */
=09=09=09continue;=09=09 /* Read on! */
@@ -2454,7 +2455,6 @@ #define MAX_ENCODED_BYTES 16
=09=09 else
=09=09 {
=09=09 const unsigned char *p =3D coding->destination;
-=09=09 eassert (coding->carryover_bytes =3D=3D 0);
=09=09 n =3D 0;
=09=09 while (n < coding->produced_char)
=09=09=09{
--=20
2.51.0
From 5504ad38ed14e31faed48b124823c428e2cdfa9a Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Tue, 21 Oct 2025 20:12:46 +0000
Subject: [PATCH 6/6] Detect invalid bytes sooner in UTF-8 decoding (bug#799=
61)
* src/coding.c (UTF_8_3_OCTET_LEADING_P): New macro.
(detect_coding_utf_8):
(decode_coding_utf_8): Use it to detect invalid sequences.
---
src/coding.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/coding.c b/src/coding.c
index a923b6bd82d..7a163691545 100644
--- a/src/coding.c
+++ b/src/coding.c
@@ -1120,6 +1120,7 @@ #define UTF_8_2_OCTET_LEADING_P(c) (((c) & 0xE0) =3D=
=3D 0xC0)
#define UTF_8_3_OCTET_LEADING_P(c) (((c) & 0xF0) =3D=3D 0xE0)
#define UTF_8_4_OCTET_LEADING_P(c) (((c) & 0xF8) =3D=3D 0xF0)
#define UTF_8_5_OCTET_LEADING_P(c) (((c) & 0xFC) =3D=3D 0xF8)
+#define UTF_8_OCTET_LEADING_P(c) ((c) >=3D 0xC0 && (c) < 0xFC)
=20
#define UTF_8_BOM_1 0xEF
#define UTF_8_BOM_2 0xBB
@@ -1173,6 +1174,8 @@ detect_coding_utf_8 (struct coding_system *coding,
=09 }
=09 continue;
=09}
+ if (!UTF_8_OCTET_LEADING_P (c))
+=09break;
ONE_MORE_BYTE (c1);
if (c1 < 0 || ! UTF_8_EXTRA_OCTET_P (c1))
=09break;
@@ -1345,6 +1348,8 @@ decode_coding_utf_8 (struct coding_system *coding)
=09{
=09 c =3D - c1;
=09}
+ else if (!UTF_8_OCTET_LEADING_P (c1))
+=09goto invalid_code;
else if (UTF_8_1_OCTET_P (c1))
=09{
=09 if (eol_dos && c1 =3D=3D '\r')
--=20
2.51.0
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 20:28:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 16:28:50 2025
Received: from localhost ([127.0.0.1]:53332 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBIyP-0007PQ-Q1
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 16:28:50 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21167)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBIyM-0007Ou-1o
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 16:28:47 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B9162100383;
Tue, 21 Oct 2025 16:28:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761078518;
bh=WZHANtndtz4uyEolNsBhr7DKloVkRXzkgzLajEfkuWo=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=K+mZHS9qXIuoiRhxSo/WbxKL2kyx/5PSE32LAO226XJB/INsSAZ78WQLkrOGMua1u
49JDNfI2uq9BpqhL7eHftwyUF2uynKgt6Nh00R9uvrOpJ3F/itAA50NZe+t9nPrdXV
7o8ktOD+/du5wwgjoead+BcxtbvhYwQjPggT431fKnrih1Ns+eCtXqY9NP8MXrDpkz
6IIUSfgZFc8NjbwyZRr3N7RYhxCQXlwg2mQSJgu2MOYVBLqCpgYCu1l8V/9brUIoyK
vNs304OQwEVXV4E7l71twSpm/tQylr92LJ0gKHCe/AMffgbSXhNbQ6gLm8ryVLlIqd
WceTUcsRf4A+w==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id BCB2F100146;
Tue, 21 Oct 2025 16:28:38 -0400 (EDT)
Received: from asado (unknown [138.0.104.197])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D3F5E1203DA;
Tue, 21 Oct 2025 16:28:36 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <87h5vst51j.fsf@HIDDEN>
Message-ID: <jwv7bwoggcm.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86v7k8wjtz.fsf@HIDDEN> <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN>
<86plagwe98.fsf@HIDDEN> <jwva51kjqnf.fsf-monnier+emacs@HIDDEN>
<86ldl4wcjr.fsf@HIDDEN> <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN>
<87sefct8rv.fsf@HIDDEN>
<jwvikg8gk4z.fsf-monnier+emacs@HIDDEN>
<87h5vst51j.fsf@HIDDEN>
Date: Tue, 21 Oct 2025 16:28:31 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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: -3.3 (---)
>> One of the reasons why I disagree is that my test of your
>> `unblock_input_to` patch suggests strongly that it fixes not only the
>> problem that we sometimes discard input (because the throw is turned
>> into a `quit`) but also the problem that we sometimes keep waiting the
>> full `sleep-for` even after a key was pressed.
>
> Hmm. Are we sure that isn't a timer thing?
Hmm... while I had had the impression that the `sleep-for` was "always"
interrupted right away (with the `unblock_input_to` patch), I can't
reproduce it now. So it seems I was confused.
> I think that makes sense (it's an API change, but a minor one).
+1
> I'm not sure why we'd also need the unblock_input_to change, but it
> probably wouldn't hurt.
I'm tempted to stay on the conservative side and just add there
a comment pointing to this discussion, but without actually changing
the code.
> And we definitely need the memq_no_signal change because the original
> bug, with a 3-byte UTF-8 character sent in a single syscall, manifests
> there at least some of the time.
I have no idea about that because I don't understand how it relates.
Can you still turn a throw-on-input into a quit that discards some bytes
after applying just my `throw-on-input` patch?
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 19:44:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 15:44:56 2025
Received: from localhost ([127.0.0.1]:53214 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBIHv-0004fO-Or
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 15:44:56 -0400
Received: from mail-4322.protonmail.ch ([185.70.43.22]:38579)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vBIHt-0004es-3l
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 15:44:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1761075886; x=1761335086;
bh=uTmDMFPCJ/plHb0D1IKD5NAumORrB8Lp/Z7e2O/bol4=;
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;
b=TwDyNSKyEqVDhQwJCLy0u6cDl4UCPaTN5qhRAwONlHdpFcIhZEisGmQVx2zFaVBwG
2VRqz5rQ3iOs02z/5xIWb51F3p/1gtD17yuE+2Tit8NmNihoBgjYxcMY0pyx/9OvKW
yXpje2Bqwi3bWWysSjYB0I7MWknEJXT/mjek1/gsw4yHSEs8zJNJwJ2vkyhulbXIOR
GyspkVJi17s+Cu3Go732b9lG86PpMcbZq+J20AAwo/iFb5smE1nkKlITDb4/K5u4UC
Ft7xQM7yroM58fBYFLwkyOGdwP1Y+nTBALPLYh9k7tFzH8sALbB/ETUAjQEB1Qqs9B
tQ0EGGC6gTRmw==
Date: Tue, 21 Oct 2025 19:44:41 +0000
To: Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
Message-ID: <87h5vst51j.fsf@HIDDEN>
In-Reply-To: <jwvikg8gk4z.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86v7k8wjtz.fsf@HIDDEN> <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN>
<86plagwe98.fsf@HIDDEN> <jwva51kjqnf.fsf-monnier+emacs@HIDDEN>
<86ldl4wcjr.fsf@HIDDEN> <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN>
<87sefct8rv.fsf@HIDDEN> <jwvikg8gk4z.fsf-monnier+emacs@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 6acb201dc46e6fd4113f7aa3045c749f08b258c6
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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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 (-)
"Stefan Monnier" <monnier@HIDDEN> writes:
>> Again, my minimal suggestion is to change this:
>>
>> /* If we're inside while-no-input, and this event qualifies
>> as input, set quit-flag to cause an interrupt. */
>> if (!NILP (Vthrow_on_input)
>> && !is_ignored_event (event))
>> Vquit_flag =3D Vthrow_on_input;
>>
>> to
>>
>> /* If we're inside while-no-input, and this event qualifies
>> as input, set quit-flag to cause an interrupt. */
>> if (!NILP (Vthrow_on_input)
>> && !is_ignored_event (event)
>> && !already_processing_throw_on_input)
>> Vquit_flag =3D Vthrow_on_input;
>>
>> Keep processing input, no buffer overflows caused by new input arriving
>> while we're in an unwind handler or something, keep handling regular
>> quits.
>
> One of the reasons why I disagree is that my test of your
> `unblock_input_to` patch suggests strongly that it fixes not only the
> problem that we sometimes discard input (because the throw is turned
> into a `quit`) but also the problem that we sometimes keep waiting the
> full `sleep-for` even after a key was pressed.
Hmm. Are we sure that isn't a timer thing?
1. evaluate (while-no-input (sleep-for 60.0))
2. hit a key
3. a delay of a few seconds, but not anywhere near a minute
4. character shows.
5. switch to fundamental mode
6. disable eldoc mode
7. cancel all timers
8. evaluate (while-no-input (sleep-for 60.0)) again
9. hit a key
10. wait for a whole minute
11. character shows
12. evaluate (run-with-timer 0.01 0.1 (lambda ()))
13. evaluate (while-no-input (sleep-for 60.0) again
14. hit a key
15. "immediate" response
Seems to work the same with and without the unblock_input_to change.
IOW, I think that it's about 4 seconds in some cases is a coincidence,
because Emacs often has 5-second-interval timers.
>>> I personally like Pip Cet's patch, to be honest. If the
>> I like my patch, too, because throwing is a Lisp interpreter thing and
>> it shouldn't affect how we handle input, but it doesn't fix this problem
>> because an unwind handler might call maybe_quit which also gobbles
>> input.
>
> Maybe in addition to the `unblock_input_to` we should do something like:
>
> diff --git a/src/eval.c b/src/eval.c
> index 2dc14b6d431..ab12f1ac150 100644
> --- a/src/eval.c
> +++ b/src/eval.c
> @@ -1854,10 +1860,13 @@ process_quit_flag (void)
> {
> Lisp_Object flag =3D Vquit_flag;
> Vquit_flag =3D Qnil;
> if (EQ (flag, Qkill_emacs))
> Fkill_emacs (Qnil, Qnil);
> if (EQ (Vthrow_on_input, flag))
> - Fthrow (Vthrow_on_input, Qt);
> + {
> + Vthrow_on_input =3D Qnil;
> + Fthrow (flag, Qt);
> + }
> quit ();
> }
>
> IOW, "consume" the `throw-on-input`.
I think that makes sense (it's an API change, but a minor one). I'm not
sure why we'd also need the unblock_input_to change, but it probably
wouldn't hurt.
And we definitely need the memq_no_signal change because the original
bug, with a 3-byte UTF-8 character sent in a single syscall, manifests
there at least some of the time.
My suggestion is to fix those three, close this bug once it's confirmed
fixed, and open new bugs for the tangential bugs: UTF-8 handling,
carryover bytes in keyboard.c, and (while-no-input (sleep-for 60.0))
waiting for the next timer to fire.
Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 19:04:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 15:04:19 2025
Received: from localhost ([127.0.0.1]:53049 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBHed-0001zW-7X
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 15:04:19 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21660)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBHeZ-0001zH-MB
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 15:04:17 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E43DE81697;
Tue, 21 Oct 2025 15:04:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761073449;
bh=DLuGNalHeHqW0xPntEpnNVAKIrXzqjBR7WDlkZGnbL4=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=pgfTtQr9ljAeNh040nrTvJCIkPGNIK5FTJaxYpYAtQn3zjDHFsgwPeJcXyqODCMYK
ibZg3TSB8NGDMfMgUjx4+zS33vdyucFM1vske5LMbm242c/i/SeWQj7JRtbP8cERc3
lcuqejAiq+rxXZC436NBg5SlsxiWOHE9wey78AvmdBlIdGjp9K2NAkaeck+VFNU2JI
ssXawDNBLAOdh3eutmiR6ly3zOA8JoqdPX/QQDCQVze0q1sYAwoYq6lsCpV/lcOX+p
fW+k08JRtAArg8VkeK5CydjZsiXVvCoK3t9F2GMB6WLkcTnex6aen7d04R6haXtbMR
4oSKlPODQk16Q==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id F15AF8053B;
Tue, 21 Oct 2025 15:04:08 -0400 (EDT)
Received: from asado (unknown [138.0.104.197])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A89511200EB;
Tue, 21 Oct 2025 15:04:06 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <87sefct8rv.fsf@HIDDEN>
Message-ID: <jwvikg8gk4z.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<867bwpy1gu.fsf@HIDDEN> <875xc9wftk.fsf@HIDDEN>
<86v7k8wjtz.fsf@HIDDEN> <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN>
<86plagwe98.fsf@HIDDEN> <jwva51kjqnf.fsf-monnier+emacs@HIDDEN>
<86ldl4wcjr.fsf@HIDDEN> <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN>
<87sefct8rv.fsf@HIDDEN>
Date: Tue, 21 Oct 2025 15:04:01 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.350 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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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: -3.3 (---)
> Again, my minimal suggestion is to change this:
>
> /* If we're inside while-no-input, and this event qualifies
> as input, set quit-flag to cause an interrupt. */
> if (!NILP (Vthrow_on_input)
> && !is_ignored_event (event))
> Vquit_flag = Vthrow_on_input;
>
> to
>
> /* If we're inside while-no-input, and this event qualifies
> as input, set quit-flag to cause an interrupt. */
> if (!NILP (Vthrow_on_input)
> && !is_ignored_event (event)
> && !already_processing_throw_on_input)
> Vquit_flag = Vthrow_on_input;
>
> Keep processing input, no buffer overflows caused by new input arriving
> while we're in an unwind handler or something, keep handling regular
> quits.
One of the reasons why I disagree is that my test of your
`unblock_input_to` patch suggests strongly that it fixes not only the
problem that we sometimes discard input (because the throw is turned
into a `quit`) but also the problem that we sometimes keep waiting the
full `sleep-for` even after a key was pressed.
>> I personally like Pip Cet's patch, to be honest. If the
> I like my patch, too, because throwing is a Lisp interpreter thing and
> it shouldn't affect how we handle input, but it doesn't fix this problem
> because an unwind handler might call maybe_quit which also gobbles
> input.
Maybe in addition to the `unblock_input_to` we should do something like:
diff --git a/src/eval.c b/src/eval.c
index 2dc14b6d431..ab12f1ac150 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1854,10 +1860,13 @@ process_quit_flag (void)
{
Lisp_Object flag = Vquit_flag;
Vquit_flag = Qnil;
if (EQ (flag, Qkill_emacs))
Fkill_emacs (Qnil, Qnil);
if (EQ (Vthrow_on_input, flag))
- Fthrow (Vthrow_on_input, Qt);
+ {
+ Vthrow_on_input = Qnil;
+ Fthrow (flag, Qt);
+ }
quit ();
}
IOW, "consume" the `throw-on-input`.
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 18:55:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 14:55:17 2025
Received: from localhost ([127.0.0.1]:53035 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBHVt-0001Z7-0u
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 14:55:17 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:65073)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBHVp-0001YI-Fe
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 14:55:14 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DEB3644178D;
Tue, 21 Oct 2025 14:55:06 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761072906;
bh=OSOkW+hJ1L0phKCAQTdz6ByLDeoWQi+chwOO84Tyipo=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=heGu3FzFVck9tn3w+BnbXEUjSBrc8HKINK9V3TiL8+QIygAwyRmMAIdLzpKUOPuiL
t5yHhnWTZAUXHyWEH32esHTtWtaa0Vr5ZAPKJPzlF7wHRTWdxC/ecwayiM8BmAPm/y
oHMRb3OyriTXvFoP9qCH9uy/4zb3BvyvItCTWFXRF4uShmZw3kqKtfYCtEgKF3FgZE
B2Q3fbAlSpIlYjRFo7tps94/jZfjXLh8cDoHGxhk+RaGEjArsB3alORKga2b1T7o56
fCRJPUzWemJh/2drFhC4kv91WiHOhrT60RBRDq0zKJXxHxImY2YGDsDONMLwlajGmF
bRNPdRgEwJ5Ow==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0BF7C441564;
Tue, 21 Oct 2025 14:55:06 -0400 (EDT)
Received: from asado (unknown [138.0.104.197])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0DE9A1203DF;
Tue, 21 Oct 2025 14:55:03 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <87y0p4t93w.fsf@HIDDEN>
Message-ID: <jwvo6q0gk83.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<875xc9wftk.fsf@HIDDEN> <86v7k8wjtz.fsf@HIDDEN>
<jwvms5kjsfx.fsf-monnier+emacs@HIDDEN>
<87y0p4t93w.fsf@HIDDEN>
Date: Tue, 21 Oct 2025 14:55:00 -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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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: -3.3 (---)
> Can you try this (I'm still trying to figure out why I'm not seeing this
> bug: I think my xterm sends UTF-8 characters using a single syscall, and
FWIW, my test case is pure ASCII:
(while-no-input (sleep-for 4))
C-x C-e
a b
where the `a` and `b` are typed "at the same time".
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 18:24:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 14:24:18 2025
Received: from localhost ([127.0.0.1]:53003 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBH1t-0008Aj-Gz
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 14:24:17 -0400
Received: from mail-4316.protonmail.ch ([185.70.43.16]:31711)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vBH1q-0008AT-D6
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 14:24:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1761071047; x=1761330247;
bh=JEtpfrpRyMcelC/5WQldujtiGQSR34+/0AfXSjW+/vQ=;
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;
b=qigRABesC1ZegNIemV0E39gCN/HhFaSyJkh06vngCGzs8vC+QTekYU6mJcc4yGcPj
WS2SGOCD5Ep+iiG2IRt/mmyEP1v6KlkfMeJR6AoAHGqtPS7DPfcib3J7Q3JPkijHXe
17NuuwU1FzABIDSMR36fDfeF4BmSB5/XCIWJIGqpbFkBo1NUc5KthfqikFzUrU5PUq
cXKc2Jt0bghVhykxF9OO+CTThKaLUCCfvVrZ9I5rfqK4ZG17RfyIl8JZ3BUVTzOcyv
JqiNHfFzLMmlEsj5p7FptNBh1ER3Dbz8xgGIV2U1TvkjvBOtjD/Ers+++Mz6AhT0Z+
0RAi5h3i59YLA==
Date: Tue, 21 Oct 2025 18:24:03 +0000
To: Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
Message-ID: <87sefct8rv.fsf@HIDDEN>
In-Reply-To: <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<867bwpy1gu.fsf@HIDDEN> <875xc9wftk.fsf@HIDDEN>
<86v7k8wjtz.fsf@HIDDEN> <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN>
<86plagwe98.fsf@HIDDEN> <jwva51kjqnf.fsf-monnier+emacs@HIDDEN>
<86ldl4wcjr.fsf@HIDDEN> <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: b158cad0345bba8fb46bcd2bfce8b398250a7225
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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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 (-)
"Stefan Monnier" <monnier@HIDDEN> writes:
>> I guess this means we just read the character that was typed by the
>> user and buffered by the TTY driver? Which leads me to a different
>> suggestion: don't read input in process_pending_signals while
>> processing Fthrow which was caused by while-no-input. Does that make
>> sense?
>
> That's similar to my suggestion, so yes I think it makes sense.
> In both cases we want to reduce the amount of "process_pending_signals
> work" being done during an "Fthrow which was caused by while-no-input".
> I suggest to do absolutely no "process_pending_signals work"
> whereas you suggest to still perform the `do_pending_atimers` but skip
> the `handle_async_input`? Should we still set `pending_signals` to
> false, then? Why do you think it's important to keep the
> `do_pending_atimers`?
Again, my minimal suggestion is to change this:
/* If we're inside while-no-input, and this event qualifies
as input, set quit-flag to cause an interrupt. */
if (!NILP (Vthrow_on_input)
&& !is_ignored_event (event))
Vquit_flag =3D Vthrow_on_input;
to
/* If we're inside while-no-input, and this event qualifies
as input, set quit-flag to cause an interrupt. */
if (!NILP (Vthrow_on_input)
&& !is_ignored_event (event)
&& !already_processing_throw_on_input)
Vquit_flag =3D Vthrow_on_input;
Keep processing input, no buffer overflows caused by new input arriving
while we're in an unwind handler or something, keep handling regular
quits.
We could *probably* get away with defining Vthrew_on_input and setting
it to Vthrow_on_input, then refusing to throw again if the two are
equal. It would be an API change, but this API is very special to begin
with.
> I personally like Pip Cet's patch, to be honest. If the
I like my patch, too, because throwing is a Lisp interpreter thing and
it shouldn't affect how we handle input, but it doesn't fix this problem
because an unwind handler might call maybe_quit which also gobbles
input.
Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 18:17:15 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 14:17:15 2025
Received: from localhost ([127.0.0.1]:52994 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBGv4-0007ts-Ir
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 14:17:15 -0400
Received: from mail-10629.protonmail.ch ([79.135.106.29]:16241)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vBGuy-0007tO-Bv
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 14:17:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1761070621; x=1761329821;
bh=aBe4+6KuW03tM+IWU1BVTOkH+2fB26WAValwnex8HLU=;
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;
b=ppsKyTJg7OYRRqa9TbCCcHI2wsqmOGBu8RPYzQxZf4NHKGsamxRirKxcYYPovdQV/
w92bqWJw2RrAUBa8Dk/OxLV5o6kMl3YgHjBAehZ6XRFDd6nzSNyGzw/yYx5s6xR2rY
sY7t1+NqlmYCqp1Vh1QNL5cMbFEiBx2lbYmvOgZyJM/7N/5SlIgxONlfiR3fFvHRl8
zVAuhcjxb1+Ws/v/flWQ4dZcPAS5Skx3CGMGMudbNHEl+CRa7/m9/WzMt5hayBupyA
NGPD8EnOyx2Q5ZO6FSOUp3oYNEgR6osBbQURN5n7KIVwYSWVhNkJzoTX2BOCO+B/u8
TAKHjuJ4MhVhg==
Date: Tue, 21 Oct 2025 18:16:51 +0000
To: Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
Message-ID: <87y0p4t93w.fsf@HIDDEN>
In-Reply-To: <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<875xc9wftk.fsf@HIDDEN> <86v7k8wjtz.fsf@HIDDEN>
<jwvms5kjsfx.fsf-monnier+emacs@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 3adad22fc2640aa5f93c81fa3a45928cf016dfe1
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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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 (-)
"Stefan Monnier" <monnier@HIDDEN> writes:
>> See the backtrace below: it clearly shows that quit-flag had the value
>> 'input' when we entered process_quit_flag (and yes, it resets that to
>> nil, but the original value is in 'flag'). Can you explain the fact
>> that we 'quit' at the end of process_quit_flag (and more generally
>> what the backtrace says)?
>
> My understanding is that the following happens:
>
> - We read an input byte.
> - We set `quit-flag` to `input`.
> - `process_quit_flag` gets called, resets `quit0-flag` and calls
> `Fthrow`, which calls `unwind_to_catch`.
> - `unwind_to_catch` calls `unblock_input_to` which calls
> `process_pending_signals`.
> - While processing pending input we read a second byte.
> - This sets `quit-flag` to `input` *again*.
> - `unwind_to_catch` finishes, unbinds `throw-on-input`, and longjumps.
The first thing unbind_to does is grab the quit flag and clear it, and
the last thing it does is to restore it.
> - Now `quit-flag` is set to `input` but `throw-on-input` is nil, so at
> the next quit-check `process_quit_flag` calls `quit`.
>
> The only hole remaining in my above theory is that I was not able to
> catch the "unbinds `throw-on-input` while `quit-flag` is set", despite:
>
> diff --git a/src/eval.c b/src/eval.c
> index 2dc14b6d431..15af1bd0f66 100644
> --- a/src/eval.c
> +++ b/src/eval.c
> @@ -3807,6 +3815,11 @@ do_one_unbind (union specbinding *this_binding=
, bool unwinding,
> { /* If variable has a trivial value (no forwarding), and isn'=
t
> trapped, we can just set it. */
> Lisp_Object sym =3D specpdl_symbol (this_binding);
> + if (EQ (sym, Qthrow_on_input)
> + && EQ (Vquit_flag, Vthrow_on_input))
> + {
> + fprintf (stderr, "Leaking a Vthrow_on_input quit-flag\n")=
;
> + }
> if (SYMBOLP (sym) && XSYMBOL (sym)->u.s.redirect =3D=3D SYMBO=
L_PLAINVAL)
> {
> if (XSYMBOL (sym)->u.s.trapped_write =3D=3D SYMBOL_UNTRAP=
PED_WRITE)
That won't work, because of the above clearing of the quit flag. We
need to check whether quitf (currently a local variable in unbind_to) is
equal to Vthrow_on_input.
Can you try this (I'm still trying to figure out why I'm not seeing this
bug: I think my xterm sends UTF-8 characters using a single syscall, and
yours might use one per byte? If you could strace | grep FIONREAD to see
how many bytes arrive at once, that'd help my curiousity)?
diff --git a/src/eval.c b/src/eval.c
index 0c29de9f3ad..3a933aa7a93 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -3765,7 +3765,7 @@ record_unwind_protect_module (enum specbind_tag kind,=
void *ptr)
=20
static void
do_one_unbind (union specbinding *this_binding, bool unwinding,
- enum Set_Internal_Bind bindflag)
+ enum Set_Internal_Bind bindflag, Lisp_Object quitf)
{
KBOARD *kbdwhere =3D NULL;
=20
@@ -3810,6 +3810,11 @@ do_one_unbind (union specbinding *this_binding, bool=
unwinding,
{ /* If variable has a trivial value (no forwarding), and isn't
=09 trapped, we can just set it. */
=09Lisp_Object sym =3D specpdl_symbol (this_binding);
+
+=09if (EQ (sym, intern_c_string ("throw-on-input")) && EQ (quitf, Vthrow_o=
n_input))
+ {
+ fprintf (stderr, "Leaking a Vthrow_on_input quit-flag\n");
+ }
=09if (SYMBOLP (sym) && XSYMBOL (sym)->u.s.redirect =3D=3D SYMBOL_PLAINVAL=
)
=09 {
=09 if (XSYMBOL (sym)->u.s.trapped_write =3D=3D SYMBOL_UNTRAPPED_WRITE)
@@ -3825,6 +3830,10 @@ do_one_unbind (union specbinding *this_binding, bool=
unwinding,
kbdwhere =3D specpdl_kboard (this_binding);
FALLTHROUGH;
case SPECPDL_LET_DEFAULT:
+ if (EQ (specpdl_symbol (this_binding), intern_c_string ("throw-on-in=
put")) && EQ (quitf, Vthrow_on_input))
+=09{
+=09 fprintf (stderr, "Leaking a Vthrow_on_input quit-flag\n");
+=09}
set_default_internal (specpdl_symbol (this_binding),
specpdl_old_value (this_binding),
bindflag, kbdwhere);
@@ -3915,7 +3924,7 @@ unbind_to (specpdl_ref count, Lisp_Object value)
union specbinding this_binding;
this_binding =3D *--specpdl_ptr;
=20
- do_one_unbind (&this_binding, true, SET_INTERNAL_UNBIND);
+ do_one_unbind (&this_binding, true, SET_INTERNAL_UNBIND, quitf);
}
=20
if (NILP (Vquit_flag) && !NILP (quitf))
> @@ -3822,6 +3835,11 @@ do_one_unbind (union specbinding *this_binding=
, bool unwinding,
> kbdwhere =3D specpdl_kboard (this_binding);
> FALLTHROUGH;
> case SPECPDL_LET_DEFAULT:
> + if (EQ (specpdl_symbol (this_binding), Qthrow_on_input)
> + && EQ (Vquit_flag, Vthrow_on_input))
> + {
> + fprintf (stderr, "Leaking a Vthrow_on_input quit-flag\n")=
;
> + }
> set_default_internal (specpdl_symbol (this_binding),
> specpdl_old_value (this_binding),
> bindflag, kbdwhere);
>
> Not sure if it's because of a problem in the above patch (can the
> unbind go through some other code path?) or because my theory is not
> quite right.
> In any case, it's clear to me that when `process_quit_flag` calls
> `Fthrow`, we should not end up calling `process_pending_signals` before
> the long jump.
I'm not sure I agree. I think it would be better to call
process_pending_signals as we do now, but to remember that a
throw-on-input is in progress so we don't trigger another one.
Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 15:56:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 11:56:49 2025
Received: from localhost ([127.0.0.1]:52622 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBEjA-0007Wm-UA
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 11:56:49 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58193)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBEj7-0007WM-PP
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 11:56:46 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CB3DF441324;
Tue, 21 Oct 2025 11:56:39 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761062198;
bh=g1Xx4zojSz95qiWcCXRlflCz4MjSGbB9qM3AZpcmjiA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=NpqDXDQ1WI2OkuvY8//OLN2JyPAsN5wqShtLOTFRffD0oewCftw+FcVFsKWsQ0+4x
Rdnr4+eW5ZXJyKqdHB3O5i03MSx3yY6mis1zvI9/UeUeF5SQGPVJXtvh1j2qMWK+tP
G7cs1aJwc7LBdXzZyAMo1uQUMoET5RGZFaAaN9YDRsCpLUKHqwJFoypOXNIzHJ+rga
iTxOCf+s2hp1vNhK178w+9EjijOpxvNYkrq3UOGDoJREqbehouGl0XEP45DhSfZZY1
VElKrf4dqXvxLUoBvW9fCSJ2X/XloR9bREbNVbE9zD825SaIHhjqob2jTzk0JMFWGX
mqda10RqxUckQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CD3524410DF;
Tue, 21 Oct 2025 11:56:38 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5FC89120346;
Tue, 21 Oct 2025 11:56:37 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <87cy6gvkaf.fsf@HIDDEN>
Message-ID: <jwvh5vsi741.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
<jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
<jwva51lmif6.fsf-monnier+emacs@HIDDEN>
<87ldl5uui2.fsf@HIDDEN>
<jwvldl5kvi5.fsf-monnier+emacs@HIDDEN>
<87cy6gvkaf.fsf@HIDDEN>
Date: Tue, 21 Oct 2025 11:56: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.074 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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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: -3.3 (---)
>>> diff --git a/src/keyboard.c b/src/keyboard.c
>>> index a9cbd107dde..4fe0d9f836f 100644
>>> --- a/src/keyboard.c
>>> +++ b/src/keyboard.c
>>> @@ -8318,6 +8318,8 @@ process_pending_signals (void)
>>> void
>>> unblock_input_to (int level)
>>> {
>>> + if (interrupt_input_blocked == level)
>>> + return;
>>> interrupt_input_blocked = level;
>>> if (level == 0)
>>> {
>>
>> That seems to help, yes. I'm not able to reproduce the problem here
>> after installing it.
>> I don't understand enough of what it does to be sure that it would fix
>> it in all cases, OTOH (nor whether it's safe for `totally_unblock_input`).
>
> I don't think it fixes anything!
What makes you say so?
AFAICT it does: it stops `unwind_to_catch` from running
`process_pending_signals` in the case we're interested in, which is what
we want (tho it also does so in many other cases as well, and I'm not
100% sure it's right, tho I get the impression that it should be
harmless in those cases).
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 15:50:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 11:50:32 2025 Received: from localhost ([127.0.0.1]:52581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vBEd6-0006y8-6q for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 11:50:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41652) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vBEd3-0006xX-0I for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 11:50:29 -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 1vBEcu-0007Dc-Mg; Tue, 21 Oct 2025 11:50:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Qz6Tszmy41xLCytq3mg9G1pF+GWbIgRX+BiANKYt9lc=; b=IAgIXgQbF6Kx hGb1UdxE3N5bH/qfIXly0sreU2Zn9tPfFUXzaDwsrYZYKBYfiPU9EJeTL1uVfHRFhMcMYBLS4+6Zu k5hLQTZPwdUusvmjSOzAuwEJoP5C8c/sEF9IGUa6YI0Ws5M45gKC0ov8/n/Q8RqU7J4NbtepeaHbL Wr23k79Ww+BwP7DO9n1C+qxBrdYtdOe3zOSAtMptJxBcPd3YoI6fDClT9DMWwGOmJpUYScIOwcvPR 3W4p2Ce9b71TfyBoGZb+hDfix+yQiKehp4tBfz3Qg6h6vOMUgNMX72HR0x2d3HfGPrYpmzar+hPTJ RLobH3jBHminmOh4rmW9Aw==; Date: Tue, 21 Oct 2025 18:50:12 +0300 Message-Id: <86frbcw8y3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: monnier@HIDDEN, n142857@HIDDEN, pipcet@HIDDEN In-Reply-To: <86h5vsw9e6.fsf@HIDDEN> (message from Eli Zaretskii on Tue, 21 Oct 2025 18:40:33 +0300) Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN> <87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN> <875xc9wftk.fsf@HIDDEN> <86v7k8wjtz.fsf@HIDDEN> <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN> <86plagwe98.fsf@HIDDEN> <jwva51kjqnf.fsf-monnier+emacs@HIDDEN> <86ldl4wcjr.fsf@HIDDEN> <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN> <86h5vsw9e6.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79661 Cc: 79661 <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: -3.3 (---) > Cc: n142857@HIDDEN, pipcet@HIDDEN, 79661 <at> debbugs.gnu.org > Date: Tue, 21 Oct 2025 18:40:33 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > > I personally like Pip Cet's patch, to be honest. If the > > `interrupt_input_blocked` is already 0 when `unwind_to_catch` calls > > `unblock_input_to` there doesn't seem to be any urgent need to run > > `process_pending_signals`: if there's a pending signal, it must be very > > fresh since `probably_quit` would have processed it already otherwise, > > so it's not urgent (and if `probably_quit` hasn't processed it yet, then > > `probably_quit` should take care to do it soon enough anyway). > > Maybe this is the solution, then. But maybe, just for more clarity about what that change does, make it clear that it only matters when level == 0, either in a comment or by some restructuring of the conditions.
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 15:40:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 11:40:47 2025 Received: from localhost ([127.0.0.1]:52534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vBETf-0006FC-4q for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 11:40:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46096) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vBETb-0006Ee-7u for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 11:40:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vBETU-0005td-Q8; Tue, 21 Oct 2025 11:40:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=DYTj3vlTr7FbcVnLCKMeEln+PAOkmlA2zS2GYyra+Qw=; b=TiOp1mp65e6D FQ8GDkJbcOlbfF7Qxk3yN8oDbwfaop7CNv3LwcfKX+hu3GODs3eD9e+b4mRTrrTEX9C5vP8Oc8PHm Bk6b1K7vV7iWNSnrsW+x2+dRaLO+6DYH6WI0yAhVNcB3z2Hkg8xTLx0B+cNKOL2aErcVcmGGZrrwl B9PYpP/m16CjvfIpgj10gopbbA5/LJvL/zS3Dwz68T9ZIT6HRgbV/qQYOENkgaGM+FripTgP7UC9p EOPV3Ipqv31e4uRt4Jq9C9LAR1tsBfIt2EArsdno7uY6bSBhd9zd9DmFfDmY0Pv2zReDM7bA9H1kx TIS2maJX/WtTWv/kxGopbQ==; Date: Tue, 21 Oct 2025 18:40:33 +0300 Message-Id: <86h5vsw9e6.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Tue, 21 Oct 2025 11:12:26 -0400) Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN> <87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN> <875xc9wftk.fsf@HIDDEN> <86v7k8wjtz.fsf@HIDDEN> <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN> <86plagwe98.fsf@HIDDEN> <jwva51kjqnf.fsf-monnier+emacs@HIDDEN> <86ldl4wcjr.fsf@HIDDEN> <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79661 Cc: n142857@HIDDEN, pipcet@HIDDEN, 79661 <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: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: n142857@HIDDEN, pipcet@HIDDEN, 79661 <at> debbugs.gnu.org > Date: Tue, 21 Oct 2025 11:12:26 -0400 > > > I guess this means we just read the character that was typed by the > > user and buffered by the TTY driver? Which leads me to a different > > suggestion: don't read input in process_pending_signals while > > processing Fthrow which was caused by while-no-input. Does that make > > sense? > > That's similar to my suggestion, so yes I think it makes sense. > In both cases we want to reduce the amount of "process_pending_signals > work" being done during an "Fthrow which was caused by while-no-input". > I suggest to do absolutely no "process_pending_signals work" > whereas you suggest to still perform the `do_pending_atimers` but skip > the `handle_async_input`? Should we still set `pending_signals` to > false, then? Why do you think it's important to keep the > `do_pending_atimers`? I don't think do_pending_atimers is important, but how do you reset pending_signals safely? what if some signal is pending that is not related to input or quit? > I personally like Pip Cet's patch, to be honest. If the > `interrupt_input_blocked` is already 0 when `unwind_to_catch` calls > `unblock_input_to` there doesn't seem to be any urgent need to run > `process_pending_signals`: if there's a pending signal, it must be very > fresh since `probably_quit` would have processed it already otherwise, > so it's not urgent (and if `probably_quit` hasn't processed it yet, then > `probably_quit` should take care to do it soon enough anyway). Maybe this is the solution, then.
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 15:12:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 11:12:42 2025
Received: from localhost ([127.0.0.1]:52445 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBE2T-0004V1-Q9
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 11:12:42 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33832)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBE2Q-0004UQ-VJ
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 11:12:39 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2ACE8100412;
Tue, 21 Oct 2025 11:12:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761059551;
bh=f5tOD7Cn+L+JZiaTkEUBYeeVl5yYGhbq9vC+2XW3+KU=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=BjCIxHXa7KRz4A20z/mCQMoqqQX9AuETLUaYnxWtOCetamRbMyZXmHkYPAnNrsK1Y
ZMbNjVDrwHJovADNY97lUvcKKfyH9Cyan5QNhqMvUZQ5+4u8fwrloznIyDFpYD7wnE
oynAtmPz8dApGoVeUIRquAnoLR0QSHeSOwFqaq9ru83YNPUc1LD/2eRzPxqfjJtYAI
2UpVqO77u5a2lbc2+0GI3EgFz8lV6UlktdMWxIuePuafdRCt7NhdTuW/n0sRKHV5Is
lL05cq++gI2V1w82Z1XBuHNPrpOeU1DH5BdC2fAGqz9UjJkY9s7+VaqmNWjtUA9u/0
CqJFsHO67rotg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A0F381000BC;
Tue, 21 Oct 2025 11:12:31 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 26A9E12041A;
Tue, 21 Oct 2025 11:12:29 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <86ldl4wcjr.fsf@HIDDEN>
Message-ID: <jwvy0p4ia0t.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<875xc9wftk.fsf@HIDDEN> <86v7k8wjtz.fsf@HIDDEN>
<jwvms5kjsfx.fsf-monnier+emacs@HIDDEN> <86plagwe98.fsf@HIDDEN>
<jwva51kjqnf.fsf-monnier+emacs@HIDDEN> <86ldl4wcjr.fsf@HIDDEN>
Date: Tue, 21 Oct 2025 11:12:26 -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.066 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: 79661
Cc: n142857@HIDDEN, pipcet@HIDDEN, 79661 <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: -3.3 (---)
> I guess this means we just read the character that was typed by the
> user and buffered by the TTY driver? Which leads me to a different
> suggestion: don't read input in process_pending_signals while
> processing Fthrow which was caused by while-no-input. Does that make
> sense?
That's similar to my suggestion, so yes I think it makes sense.
In both cases we want to reduce the amount of "process_pending_signals
work" being done during an "Fthrow which was caused by while-no-input".
I suggest to do absolutely no "process_pending_signals work"
whereas you suggest to still perform the `do_pending_atimers` but skip
the `handle_async_input`? Should we still set `pending_signals` to
false, then? Why do you think it's important to keep the
`do_pending_atimers`?
I personally like Pip Cet's patch, to be honest. If the
`interrupt_input_blocked` is already 0 when `unwind_to_catch` calls
`unblock_input_to` there doesn't seem to be any urgent need to run
`process_pending_signals`: if there's a pending signal, it must be very
fresh since `probably_quit` would have processed it already otherwise,
so it's not urgent (and if `probably_quit` hasn't processed it yet, then
`probably_quit` should take care to do it soon enough anyway).
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 14:50:44 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 10:50:44 2025
Received: from localhost ([127.0.0.1]:52362 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBDhE-0002rq-88
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 10:50:44 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:5973)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBDhC-0002rX-1O
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 10:50:43 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6013681679;
Tue, 21 Oct 2025 10:50:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761058235;
bh=NrrJk4PiJMLLTvAHmFr6CB3pqhc6S7lvEh2+hcLIVtY=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=PLZce5Veq39aD2C6BT+nxAFAeqeoVaqPiFsDqflMmkh0hQ70yne2AqxYFDQqtNiY/
sGvbzn/77NMc/4Bn/G7mCHeVcb7Fl6Zeto+Lpax1+yugIFo2VImgq705mxrsVjAVBO
Qga/5nvGiZSVIYlAj3lP5oxa6CSbCU+OLsyzdAYJV8BJ0A2C4RcUcV4OGPiQ6hAy33
n4C4CWpsUrBpmfPdd9aRXdUXT3kkpV2HPJmjtFwA+EIAIyg/J6IXUxG+phS240nNJ3
oOm+pUJzJLt38CYbaMoz/ShhGMKiudLYhjj4m9u/rS8S2Yjuw7OppwCb2rzfPrI0YG
vISsdy3WqvGoQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6770B8071A;
Tue, 21 Oct 2025 10:50:35 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EBDD51201F9;
Tue, 21 Oct 2025 10:50:33 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN>
Message-ID: <jwv4irsjosn.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<875xc9wftk.fsf@HIDDEN> <86v7k8wjtz.fsf@HIDDEN>
<jwvms5kjsfx.fsf-monnier+emacs@HIDDEN>
Date: Tue, 21 Oct 2025 10:50:30 -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.877 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
KAM_STOCKGEN 1.5 Email Contains Generic Pump & Dump Stock Tip
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79661
Cc: n142857@HIDDEN, Pip Cet <pipcet@HIDDEN>, 79661 <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: -3.3 (---)
> The only hole remaining in my above theory is that I was not able to
> catch the "unbinds `throw-on-input` while `quit-flag` is set", despite:
>
> diff --git a/src/eval.c b/src/eval.c
> index 2dc14b6d431..15af1bd0f66 100644
> --- a/src/eval.c
> +++ b/src/eval.c
> @@ -3807,6 +3815,11 @@ do_one_unbind (union specbinding *this_binding, bool unwinding,
> { /* If variable has a trivial value (no forwarding), and isn't
> trapped, we can just set it. */
> Lisp_Object sym = specpdl_symbol (this_binding);
> + if (EQ (sym, Qthrow_on_input)
> + && EQ (Vquit_flag, Vthrow_on_input))
> + {
> + fprintf (stderr, "Leaking a Vthrow_on_input quit-flag\n");
> + }
> if (SYMBOLP (sym) && XSYMBOL (sym)->u.s.redirect == SYMBOL_PLAINVAL)
> {
> if (XSYMBOL (sym)->u.s.trapped_write == SYMBOL_UNTRAPPED_WRITE)
> @@ -3822,6 +3835,11 @@ do_one_unbind (union specbinding *this_binding, bool unwinding,
> kbdwhere = specpdl_kboard (this_binding);
> FALLTHROUGH;
> case SPECPDL_LET_DEFAULT:
> + if (EQ (specpdl_symbol (this_binding), Qthrow_on_input)
> + && EQ (Vquit_flag, Vthrow_on_input))
> + {
> + fprintf (stderr, "Leaking a Vthrow_on_input quit-flag\n");
> + }
> set_default_internal (specpdl_symbol (this_binding),
> specpdl_old_value (this_binding),
> bindflag, kbdwhere);
>
> Not sure if it's because of a problem in the above patch (can the
> unbind go through some other code path?) or because my theory is not
> quite right.
The above patch is not effective because `unbind_to` sets `Vquit_flag`
to nil temporarily. The patch below *does* catch the sucker in the act:
diff --git a/src/eval.c b/src/eval.c
index 2dc14b6d431..e67c48a0b39 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -3912,6 +3923,12 @@ unbind_to (specpdl_ref count, Lisp_Object value)
union specbinding this_binding;
this_binding = *--specpdl_ptr;
+ if (EQ (quitf, Vthrow_on_input)
+ && this_binding.kind >= SPECPDL_LET
+ && EQ (specpdl_symbol (&this_binding), Qthrow_on_input))
+ {
+ fprintf (stderr, "Leaking a Vthrow_on_input quit-flag\n");
+ }
do_one_unbind (&this_binding, true, SET_INTERNAL_UNBIND);
}
So now I get the following trace in stderr:
Setting Vquit_flag = Vthrow_on_input
setting Vquit_flag = Qnil
Fthrow (Vthrow_on_input, Qt)
entering unwind_to_catch...
Setting Vquit_flag = Vthrow_on_input
unwind_to_catch starting unbind_to loop with quit-flag...
Leaking a Vthrow_on_input quit-flag
...sys_longjmp
setting Vquit_flag = Qnil
entering quit ()
entering unwind_to_catch...
unwind_to_catch starting unbind_to loop...
...sys_longjmp
setting Vquit_flag = Qnil
entering quit ()
which confirms my theory (no idea why we got two `quit`s here).
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 14:33:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 10:33:20 2025 Received: from localhost ([127.0.0.1]:52288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vBDQO-0001mT-7K for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 10:33:20 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:38560) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vBDQK-0001m8-Oc for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 10:33: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 1vBDQF-0004hl-CK; Tue, 21 Oct 2025 10:33:11 -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=5L/21hIVz9kHTq7c9bJrOQOU496nPKYS/dg21+wS0m0=; b=YZOi3eIIQBPF GAJk0mZeBRThAKgDKvgpXoix35dY1LmwqOfS789kTDS4wJFQtKVKmIpUflyMuLXIgGA57DIy07gcp 1WOAeAs37oJIovzBTr3cr0dsLz6QiuEjJzNS5i2RawgUSZ1GlaQiAiJiZV6KnuR+cVh/hbDhsW+fg 6ONg5buJtydw2a2lWMYQC+yfTR00qI0EvGCmajho2EY2Nq7rKOsfssLmOTW86s1Ibzvez0dmBHzBY xNHMgY2af2JxKKooGMa4VXJdTS3LHVEi+R9ZmVl/oqawp9nM5tq1y6UPqwoEeeRnIYmY7iNPzAPTj l8ExZfiMNfeIhJHj7RLGiA==; Date: Tue, 21 Oct 2025 17:32:24 +0300 Message-Id: <86ldl4wcjr.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwva51kjqnf.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Tue, 21 Oct 2025 10:10:35 -0400) Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN> <87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN> <875xc9wftk.fsf@HIDDEN> <86v7k8wjtz.fsf@HIDDEN> <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN> <86plagwe98.fsf@HIDDEN> <jwva51kjqnf.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79661 Cc: n142857@HIDDEN, pipcet@HIDDEN, 79661 <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: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: n142857@HIDDEN, pipcet@HIDDEN, 79661 <at> debbugs.gnu.org > Date: Tue, 21 Oct 2025 10:10:35 -0400 > > Eli Zaretskii [2025-10-21 16:55:31] wrote: > > >> From: Stefan Monnier <monnier@HIDDEN> > >> Cc: Pip Cet <pipcet@HIDDEN>, n142857@HIDDEN, 79661 <at> debbugs.gnu.org > >> Date: Tue, 21 Oct 2025 09:41:57 -0400 > >> > >> > See the backtrace below: it clearly shows that quit-flag had the value > >> > 'input' when we entered process_quit_flag (and yes, it resets that to > >> > nil, but the original value is in 'flag'). Can you explain the fact > >> > that we 'quit' at the end of process_quit_flag (and more generally > >> > what the backtrace says)? > >> > >> My understanding is that the following happens: > >> > >> - We read an input byte. > >> - We set `quit-flag` to `input`. > >> - `process_quit_flag` gets called, resets `quit0-flag` and calls > >> `Fthrow`, which calls `unwind_to_catch`. > >> - `unwind_to_catch` calls `unblock_input_to` which calls > >> `process_pending_signals`. > >> - While processing pending input we read a second byte. > > > > How can this last line happen on a TTY? Reading input in that case is > > not based on signals, is it? So how can we read a byte while > > processing something? > > I think it goes: > > process_pending_signals => handle_async_input => gobble_input => tty_read_avail_input > > If you say that this "should be impossible" in a tty, I'll believe you. > I'm not sufficiently familiar with the way we use or not signals and > things like that. > > But the evidence is shown in my earlier backtrace: > > #0 SPECPDL_INDEX () at /home/monnier/src/emacs/main/src/lisp.h:3751 > #1 inhibit_garbage_collection () at alloc.c:5424 > #2 0x0000555e87e51659 in probably_quit () at eval.c:1867 > #3 0x0000555e87e5900d in maybe_quit () > at /home/monnier/src/emacs/main/src/lisp.h:3919 > #4 0x0000555e87e59271 in Fmemq (elt=..., list=...) at fns.c:1913 > #5 0x0000555e87dc137b in is_ignored_event (event=event@entry=0x7ffd2535d870) > at keyboard.c:13301 > #6 0x0000555e87dcf962 in kbd_buffer_store_buffered_event > (event=0x7ffd2535d870, > event@entry=0x7ffd2535c7f0, hold_quit=hold_quit@entry=0x0) > at keyboard.c:3828 > #7 0x0000555e87dcf98b in kbd_buffer_store_event_hold > (event=0x7ffd2535c7f0, hold_quit=0x0) > at /home/monnier/src/emacs/main/src/keyboard.h:510 > #8 kbd_buffer_store_event (event=event@entry=0x7ffd2535d870) > at keyboard.c:3714 > #9 0x0000555e87dd0eb8 in tty_read_avail_input > (terminal=<optimized out>, hold_quit=<optimized out>) at keyboard.c:8271 > #10 0x0000555e87dcfb47 in gobble_input () at keyboard.c:8042 > #11 0x0000555e87dcfcc7 in handle_async_input () at keyboard.c:8296 > #12 0x0000555e87dcfce0 in process_pending_signals () at keyboard.c:8310 > #13 0x0000555e87dcfd11 in unblock_input_to (level=<optimized out>) > at keyboard.c:8325 > #14 0x0000555e87e51530 in unwind_to_catch > (catch=catch@entry=0x555ea24eb890, type=type@entry=NONLOCAL_EXIT_THROW, value=..., value@entry=...) at eval.c:1414 > #15 0x0000555e87e52a17 in Fthrow (tag=..., value=..., value@entry=...) > at eval.c:1456 > #16 0x0000555e87e52dcf in process_quit_flag () I guess this means we just read the character that was typed by the user and buffered by the TTY driver? Which leads me to a different suggestion: don't read input in process_pending_signals while processing Fthrow which was caused by while-no-input. Does that make sense?
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 14:10:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 10:10:56 2025
Received: from localhost ([127.0.0.1]:52213 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBD4h-0000ap-KQ
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 10:10:56 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63926)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBD4d-0000aL-Ok
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 10:10:54 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E7EB94411E0;
Tue, 21 Oct 2025 10:10:45 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761055840;
bh=ay6JZ373PPAU9bV8pA/Oo5uDT5vAbriWxi4rPD1aUfc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=WeWTHYMUNKY8Vek2HZFUGhlqVGEabxuKATK8dR1mzHIMdZeXob9pmpnRIN/b1B6y0
0m+WVfjtbJfXeiWLksPfNu6uaPgxzn/bBCkxOzWLpswqX64rZS4fYap5Gcj0JACnTW
TqGZBTBKbG2RNhWiD+cSlXfWjZrP7L+bSZtQXqk9dphdyTtG4LG4TiouuC2vXUs/lv
Viv2OOJRAH30ZlrA7+SCQC20v7MZlyIGTfZwcIjf/p5Z3Y2b95vLc1wkvJ3VH4AsGY
iAPel+i8oXLunUEbowXInra9eF2KDjZgdQaA/NpIECGvSc8Y4rLkcLSU+g3J/kWALK
0mTN3ZNy08hTQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 547BF441226;
Tue, 21 Oct 2025 10:10:40 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D5CE11202F7;
Tue, 21 Oct 2025 10:10:38 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <86plagwe98.fsf@HIDDEN>
Message-ID: <jwva51kjqnf.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<875xc9wftk.fsf@HIDDEN> <86v7k8wjtz.fsf@HIDDEN>
<jwvms5kjsfx.fsf-monnier+emacs@HIDDEN> <86plagwe98.fsf@HIDDEN>
Date: Tue, 21 Oct 2025 10:10:35 -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.076 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: 79661
Cc: n142857@HIDDEN, pipcet@HIDDEN, 79661 <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: -3.3 (---)
Eli Zaretskii [2025-10-21 16:55:31] wrote:
>> From: Stefan Monnier <monnier@HIDDEN>
>> Cc: Pip Cet <pipcet@HIDDEN>, n142857@HIDDEN, 79661 <at> debbugs.gnu.org
>> Date: Tue, 21 Oct 2025 09:41:57 -0400
>>
>> > See the backtrace below: it clearly shows that quit-flag had the value
>> > 'input' when we entered process_quit_flag (and yes, it resets that to
>> > nil, but the original value is in 'flag'). Can you explain the fact
>> > that we 'quit' at the end of process_quit_flag (and more generally
>> > what the backtrace says)?
>>
>> My understanding is that the following happens:
>>
>> - We read an input byte.
>> - We set `quit-flag` to `input`.
>> - `process_quit_flag` gets called, resets `quit0-flag` and calls
>> `Fthrow`, which calls `unwind_to_catch`.
>> - `unwind_to_catch` calls `unblock_input_to` which calls
>> `process_pending_signals`.
>> - While processing pending input we read a second byte.
>
> How can this last line happen on a TTY? Reading input in that case is
> not based on signals, is it? So how can we read a byte while
> processing something?
I think it goes:
process_pending_signals => handle_async_input => gobble_input => tty_read_avail_input
If you say that this "should be impossible" in a tty, I'll believe you.
I'm not sufficiently familiar with the way we use or not signals and
things like that.
But the evidence is shown in my earlier backtrace:
#0 SPECPDL_INDEX () at /home/monnier/src/emacs/main/src/lisp.h:3751
#1 inhibit_garbage_collection () at alloc.c:5424
#2 0x0000555e87e51659 in probably_quit () at eval.c:1867
#3 0x0000555e87e5900d in maybe_quit ()
at /home/monnier/src/emacs/main/src/lisp.h:3919
#4 0x0000555e87e59271 in Fmemq (elt=..., list=...) at fns.c:1913
#5 0x0000555e87dc137b in is_ignored_event (event=event@entry=0x7ffd2535d870)
at keyboard.c:13301
#6 0x0000555e87dcf962 in kbd_buffer_store_buffered_event
(event=0x7ffd2535d870,
event@entry=0x7ffd2535c7f0, hold_quit=hold_quit@entry=0x0)
at keyboard.c:3828
#7 0x0000555e87dcf98b in kbd_buffer_store_event_hold
(event=0x7ffd2535c7f0, hold_quit=0x0)
at /home/monnier/src/emacs/main/src/keyboard.h:510
#8 kbd_buffer_store_event (event=event@entry=0x7ffd2535d870)
at keyboard.c:3714
#9 0x0000555e87dd0eb8 in tty_read_avail_input
(terminal=<optimized out>, hold_quit=<optimized out>) at keyboard.c:8271
#10 0x0000555e87dcfb47 in gobble_input () at keyboard.c:8042
#11 0x0000555e87dcfcc7 in handle_async_input () at keyboard.c:8296
#12 0x0000555e87dcfce0 in process_pending_signals () at keyboard.c:8310
#13 0x0000555e87dcfd11 in unblock_input_to (level=<optimized out>)
at keyboard.c:8325
#14 0x0000555e87e51530 in unwind_to_catch
(catch=catch@entry=0x555ea24eb890, type=type@entry=NONLOCAL_EXIT_THROW, value=..., value@entry=...) at eval.c:1414
#15 0x0000555e87e52a17 in Fthrow (tag=..., value=..., value@entry=...)
at eval.c:1456
#16 0x0000555e87e52dcf in process_quit_flag ()
[...]
- Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 13:56:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 09:56:21 2025 Received: from localhost ([127.0.0.1]:52146 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vBCqb-0007zj-CV for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 09:56:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47818) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vBCqX-0007zK-Cm for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 09:56:19 -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 1vBCqR-0007ll-3x; Tue, 21 Oct 2025 09:56:11 -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=Oryr1YOEqe/sauYG6qsyVISYtK7mtkMQP640CywS7P4=; b=rni3HLKW4s9o y7OF0LuE60m3n9eKKxZUqgaKLKOWfd+3NmgL0+ClURwklS7ZhDKmj1MpZ+XlvaccSt7buI/kDCEpY 0Hig9gWQUdvfnIAbdpQpjBtPI7z1B1uaR1gcYFOfLRSj2FyXmxOkBP6GR/C1EKD4/cdojnBZOKlAl H0RSxH1ZZgVGINqU7sW4kMVfn3u7NdMyCieEc7gdsG7/RRviAOF+Owf2BuhvBSbB9gfy/T4R8Y629 ULnOGXmmIWhIC87YXVkQy1BK531OoPIl3Nyxgu/UYqN/U7COVW6ywIIjujN0WCWVQ5JsWxwN6kShc mRH1S5HMPl3YCt0TJ96aDw==; Date: Tue, 21 Oct 2025 16:55:31 +0300 Message-Id: <86plagwe98.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Tue, 21 Oct 2025 09:41:57 -0400) Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN> <87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN> <875xc9wftk.fsf@HIDDEN> <86v7k8wjtz.fsf@HIDDEN> <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79661 Cc: n142857@HIDDEN, pipcet@HIDDEN, 79661 <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: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Pip Cet <pipcet@HIDDEN>, n142857@HIDDEN, 79661 <at> debbugs.gnu.org > Date: Tue, 21 Oct 2025 09:41:57 -0400 > > > See the backtrace below: it clearly shows that quit-flag had the value > > 'input' when we entered process_quit_flag (and yes, it resets that to > > nil, but the original value is in 'flag'). Can you explain the fact > > that we 'quit' at the end of process_quit_flag (and more generally > > what the backtrace says)? > > My understanding is that the following happens: > > - We read an input byte. > - We set `quit-flag` to `input`. > - `process_quit_flag` gets called, resets `quit0-flag` and calls > `Fthrow`, which calls `unwind_to_catch`. > - `unwind_to_catch` calls `unblock_input_to` which calls > `process_pending_signals`. > - While processing pending input we read a second byte. How can this last line happen on a TTY? Reading input in that case is not based on signals, is it? So how can we read a byte while processing something?
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 13:42:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 09:42:41 2025
Received: from localhost ([127.0.0.1]:50812 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBCdN-0006rB-5y
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 09:42:41 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:5491)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBCdK-0006qr-LU
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 09:42:39 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 10486100383;
Tue, 21 Oct 2025 09:42:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761054152;
bh=cD45IAhzy7//giqZ+Dj8Yil0F57aQ3+LFaMRlkxUg1A=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=HgANRnv3MB0Y+E7VPo4sVry+XtU9FPdEXEykCJGf7IvnQaGtnHMy/POWgPVHz8AJU
iH7HUlHCo2UU5h1TlHj/GDZ5J2mWj/KuLuDPhrglFYdwi2QHXvpMJ/cDKi+c8eQaKU
wjFphmM6E3jJOOuC/+9Q47xCCqzRRhN5shdqNVrclJAOD8dsQ2veoASidbpSPbNOsg
SdtkvXB5dfnJm4K2ULgJfQiclAn2Aor8dI8P7/ne6743/PgeI7DV5WchXb8T+wHHQk
F7Ulf6vfK2Qa/UtTzM7F9j2h7VzgWTLeI20nbK/3CkDM3X0No+etAtgR97FilZ/c3+
hJ9m57SFzzUQA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 30338100146;
Tue, 21 Oct 2025 09:42:32 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B8AC212022C;
Tue, 21 Oct 2025 09:42:29 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <87cy6gvkaf.fsf@HIDDEN>
Message-ID: <jwvy0p4jtkm.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
<jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
<jwva51lmif6.fsf-monnier+emacs@HIDDEN>
<87ldl5uui2.fsf@HIDDEN>
<jwvldl5kvi5.fsf-monnier+emacs@HIDDEN>
<87cy6gvkaf.fsf@HIDDEN>
Date: Tue, 21 Oct 2025 09:42:25 -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.068 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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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: -3.3 (---)
> I cannot think of a simple fix that preserves the entire throw-on-input
> API as documented.
>
> As long as while-no-input is the only user and it continues using fresh
> uninterned symbols, we could keep track of the last tag we set
> Vquit_flag to, and throw to each tag at most once. That would make the
> Lisp-side API even harder to use correctly.
Sorry, I don't understand what you're saying. What is the problem you
think needs to be fixed and why does "throw only once" make
a difference?
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 13:42:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 09:42:14 2025
Received: from localhost ([127.0.0.1]:50808 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBCcv-0006q5-Fb
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 09:42:13 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:2657)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBCcr-0006ph-Ja
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 09:42:10 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 04A69441205;
Tue, 21 Oct 2025 09:42:04 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761054122;
bh=0LlHeYFtMwPCPJEe6dzHJvy6Xsfduy2TeyIHPqopKuw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=BcQCPbhvsMss9Ndp8yt7e9ZZA2AVklbzEBHzj+pDpfBlLr3TT4ui1JTj0kIpi22U8
eLlikYeJxLwYLHOYspKCVVFUq4u7fhA+7bDKHIb5n/abk8oxzLbNzVGOIJXPqV7bc3
JPWeTIiw3t5ppkwj9zplo3ByUWXCsGdAELI/khqP4Ub5LNo7Rg7WYWSu7oyaEkPAu/
m0FXXEzy4IW9YTVhedaAa2kvkrVu3I19XhTuDN/Lz/rRi/1OeZb7w5CHRnnSBPVxfN
uFv4cYkcAw5SUMLwmYiLfRDWn+czsBjruArOJ6OlTYaInlYk22vUrIne8YpLG5eSDb
60NaPx0FxDxBg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CF38E440C1C;
Tue, 21 Oct 2025 09:42:02 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 59A5E12022C;
Tue, 21 Oct 2025 09:42:01 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <86v7k8wjtz.fsf@HIDDEN>
Message-ID: <jwvms5kjsfx.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<875xc9wftk.fsf@HIDDEN> <86v7k8wjtz.fsf@HIDDEN>
Date: Tue, 21 Oct 2025 09:41:57 -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.685 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
KAM_STOCKGEN 1.5 Email Contains Generic Pump & Dump Stock Tip
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79661
Cc: n142857@HIDDEN, Pip Cet <pipcet@HIDDEN>, 79661 <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: -3.3 (---)
> See the backtrace below: it clearly shows that quit-flag had the value
> 'input' when we entered process_quit_flag (and yes, it resets that to
> nil, but the original value is in 'flag'). Can you explain the fact
> that we 'quit' at the end of process_quit_flag (and more generally
> what the backtrace says)?
My understanding is that the following happens:
- We read an input byte.
- We set `quit-flag` to `input`.
- `process_quit_flag` gets called, resets `quit0-flag` and calls
`Fthrow`, which calls `unwind_to_catch`.
- `unwind_to_catch` calls `unblock_input_to` which calls
`process_pending_signals`.
- While processing pending input we read a second byte.
- This sets `quit-flag` to `input` *again*.
- `unwind_to_catch` finishes, unbinds `throw-on-input`, and longjumps.
- Now `quit-flag` is set to `input` but `throw-on-input` is nil, so at
the next quit-check `process_quit_flag` calls `quit`.
The only hole remaining in my above theory is that I was not able to
catch the "unbinds `throw-on-input` while `quit-flag` is set", despite:
diff --git a/src/eval.c b/src/eval.c
index 2dc14b6d431..15af1bd0f66 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -3807,6 +3815,11 @@ do_one_unbind (union specbinding *this_binding, bool unwinding,
{ /* If variable has a trivial value (no forwarding), and isn't
trapped, we can just set it. */
Lisp_Object sym = specpdl_symbol (this_binding);
+ if (EQ (sym, Qthrow_on_input)
+ && EQ (Vquit_flag, Vthrow_on_input))
+ {
+ fprintf (stderr, "Leaking a Vthrow_on_input quit-flag\n");
+ }
if (SYMBOLP (sym) && XSYMBOL (sym)->u.s.redirect == SYMBOL_PLAINVAL)
{
if (XSYMBOL (sym)->u.s.trapped_write == SYMBOL_UNTRAPPED_WRITE)
@@ -3822,6 +3835,11 @@ do_one_unbind (union specbinding *this_binding, bool unwinding,
kbdwhere = specpdl_kboard (this_binding);
FALLTHROUGH;
case SPECPDL_LET_DEFAULT:
+ if (EQ (specpdl_symbol (this_binding), Qthrow_on_input)
+ && EQ (Vquit_flag, Vthrow_on_input))
+ {
+ fprintf (stderr, "Leaking a Vthrow_on_input quit-flag\n");
+ }
set_default_internal (specpdl_symbol (this_binding),
specpdl_old_value (this_binding),
bindflag, kbdwhere);
Not sure if it's because of a problem in the above patch (can the
unbind go through some other code path?) or because my theory is not
quite right.
In any case, it's clear to me that when `process_quit_flag` calls
`Fthrow`, we should not end up calling `process_pending_signals` before
the long jump.
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 13:25:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 09:25:04 2025
Received: from localhost ([127.0.0.1]:50765 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBCMJ-0005m9-Pa
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 09:25:04 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:14467)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vBCMG-0005kn-Sl
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 09:25:01 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 64EEC440B4D;
Tue, 21 Oct 2025 09:24:54 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761053093;
bh=0q6515FBgJFdQxUw9ZwLexF+Hw5Hd1u9M9MWBzNXdsI=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=db4Mz4wE+QNv7m9m51Wc2WbIOGSZJpwG/VakF7X/FluogIQbvYicFfJTBuEbSQbCI
caRNSEJNWEeVa5HhOgbO/Q2OLxBT8pw74a77y2aH238yOvzwun1q4322TF4/nQvcQb
NjU6xJwHDUDULPCNi5gO4iGYMRpvRILW2RcCZaL+7sST0Ht0YweZFWrC8IfoWSbp2g
xTDmJ1+AYy+YBb2sijKCJ9mhpPDWfj5R3PZxZFEX3mOlQl6KaTyeqfxpd0R93uzu/B
dWcB0B8H883TIkW6RwW/mPq5W+uoKmebDkmaO6RKKs7HCWo8v6LxQpdWaa7CVCkiWG
K6JrPRT9+VN7A==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 407D5440C1C;
Tue, 21 Oct 2025 09:24:53 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C3C4112026A;
Tue, 21 Oct 2025 09:24:51 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <877bwovjg2.fsf@HIDDEN>
Message-ID: <jwvtszsjtbg.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
<jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
<87wm4puxhl.fsf@HIDDEN>
<jwvqzuxkwim.fsf-monnier+emacs@HIDDEN>
<877bwovjg2.fsf@HIDDEN>
Date: Tue, 21 Oct 2025 09:24:47 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.066 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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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: -3.3 (---)
>>> If an invalid UTF-8 sequence is followed by a valid UTF-8 character
>>> sequence, decode_coding_c_string will return with the leading byte of
>>> the second sequence as a carryover.
>>
>> Why does it do that? Why didn't it return the invalid UTF-8 sequence
>> before we even read the first byte of the following (valid) UTF-8 charac=
ter?
>
> The sequence is
>
> byte 1: <LEADING OCTET FOR 3-BYTE SEQUENCE>
> byte 2: <EXTRA OCTET>
> byte 3: <LEADING OCTET FOR 3-BYTE SEQUENCE>
> byte 4: <EXTRA OCTET>
> byte 5: <EXTRA OCTET>
Ah, right.
> There's no way to tell the sequence is invalid until we read byte 3.
Of course, we could decode the whole 5 bytes as "invalid bytes" if we
had to avoid changing `keyboard.c` =F0=9F=99=82, but yes it makes more sens=
e to
try and "resynchronize" optimistically rather than pessimistically.
>> I guess it's OK if there's a good reason for the UTF-8 decoder to behave
>> like it does.
> Both keyboard.c and coding.c need fixes, I'm afraid.
> I'll file a new bug for the UTF-8 thing. It's related only tangentially
> and the throw-no-input thing is tricky enough to fix on its own.
Agreed, thanks. Keep me in the `X-Debbugs-Cc:`.
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 11:55:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 07:55:22 2025
Received: from localhost ([127.0.0.1]:50547 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vBAxV-0000GR-Fu
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 07:55:22 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:35000)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vBAxP-0000AN-5X
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 07:55: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 1vBAxJ-00022X-1r; Tue, 21 Oct 2025 07:55: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=Ms1drSb7hgfkAGt42TnUNMSB99mRBCPMMyaPp/zlWlU=; b=oaqgMhfPGuFe
DTL6oh0XOYoQdbV/FT8h5CIcHnsIBD8SQz6AgP/rSjB5dENX5ukhpr30guqYo+RCwUk4rog5zSi7l
qou+CE8aH6PpyrzzIlc/f9/lSRc5yi/B8k5GZC8OYylTd5LGMhfdgmIPA+/KeX5ThGdkHXMrLIRLr
3ZRXnei0Sqc0PZfoz+VaSWVz81jpFIVo2gnBEd1VHXad6Bpb4qppIr1FW8mc5RYbmP5Duse1L7Eas
zxuTgnnUW6CivPUnQjYqC6lKahtFyIoO0BvybhkhlvWlN/Ku2HeShEr6zolMyTBPApLdkcA+WvMLd
D0GXN12yBfasQTZZnXxrvg==;
Date: Tue, 21 Oct 2025 14:55:04 +0300
Message-Id: <86v7k8wjtz.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <875xc9wftk.fsf@HIDDEN> (message from Pip Cet on Mon, 20
Oct 2025 19:11:19 +0000)
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<875xc9wftk.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79661
Cc: n142857@HIDDEN, monnier@HIDDEN, 79661 <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: -3.3 (---)
> Date: Mon, 20 Oct 2025 19:11:19 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: monnier@HIDDEN, n142857@HIDDEN, 79661 <at> debbugs.gnu.org
>
> "Eli Zaretskii" <eliz@HIDDEN> writes:
>
> > Where is the call to Fmemq that quits in this case? When I put a
> > breakpoint inside 'quit', I don't see Fmemq in the backtrace.
>
> When I put a breakpoint on 'quit', it doesn't trigger at all, when
> following the recipe.
The backtrace at the end of this message shows a breakpoint inside
'quit' triggering.
> Can you add a watchpoint on Vquit_flag and produce
> full backtraces of all the times when it changes?
The backtrace at the end is one such full backtrace (but without a
watchpoint on quit-flag). If I set a watchpoint and define commands
that show a backtrace, the problem disappears (I don't see a quit).
So I could only do this without the backtrace, with a single command
that is just "continue". The result is:
Thread 1 "emacs" hit Hardware watchpoint 6: globals.f_Vquit_flag
Old value = XIL(0)
New value = XIL(0x3dc05780)
0x000055db3b8e7c60 in kbd_buffer_store_buffered_event (event=0x7ffc4fcd1f10, hold_quit=<optimized out>) at keyboard.c:3830
3830 }
Thread 1 "emacs" hit Hardware watchpoint 6: globals.f_Vquit_flag
Old value = XIL(0x3dc05780)
New value = XIL(0)
unbind_to (count=..., value=XIL(0)) at eval.c:3904
3904 while (specpdl_ptr != specpdl_ref_to_ptr (count))
Thread 1 "emacs" hit Hardware watchpoint 6: globals.f_Vquit_flag
Old value = XIL(0)
New value = XIL(0x3dc05780)
unbind_to (count=..., value=XIL(0)) at eval.c:3921
3921 return value;
Thread 1 "emacs" hit Hardware watchpoint 6: globals.f_Vquit_flag
Old value = XIL(0x3dc05780)
New value = XIL(0)
unbind_to (count=..., value=XIL(0x30)) at eval.c:3904
3904 while (specpdl_ptr != specpdl_ref_to_ptr (count))
Thread 1 "emacs" hit Hardware watchpoint 6: globals.f_Vquit_flag
Old value = XIL(0)
New value = XIL(0x3dc05780)
unbind_to (count=..., value=XIL(0x30)) at eval.c:3921
3921 return value;
Thread 1 "emacs" hit Hardware watchpoint 6: globals.f_Vquit_flag
Old value = XIL(0x3dc05780)
New value = XIL(0)
unbind_to (count=..., value=XIL(0x30)) at eval.c:3904
3904 while (specpdl_ptr != specpdl_ref_to_ptr (count))
Thread 1 "emacs" hit Hardware watchpoint 6: globals.f_Vquit_flag
Old value = XIL(0)
New value = XIL(0x3dc05780)
unbind_to (count=..., value=XIL(0x30)) at eval.c:3921
3921 return value;
Thread 1 "emacs" hit Hardware watchpoint 6: globals.f_Vquit_flag
Old value = XIL(0x3dc05780)
New value = XIL(0)
process_quit_flag () at eval.c:1857
1857 if (EQ (flag, Qkill_emacs))
> > It sounds like with-local-quit (called from while-no-input) somehow
> > doesn't work in the TTY case, allowing the 'quit' call after BODY is
> > correctly interrupted. What I see in the backtrace is this:
> >
> > Thread 1 "emacs" hit Breakpoint 4, quit () at eval.c:1907
> > 1907 return signal_or_quit (Qquit, Qnil, true);
> > (gdb) bt
> > #0 quit () at eval.c:1907
> > #1 process_quit_flag () at eval.c:1861
> > #2 probably_quit () at eval.c:1869
> > #3 0x0000560a1a7b652c in maybe_quit ()
> > at /home/eliz/git/emacs/trunk/src/lisp.h:3919
> > #4 exec_byte_code
> > (fun=XIL(0), args_template=455880, nargs=2, args=0x7fe185a461c8)
> > at bytecode.c:763
> > #5 0x0000560a1a762f15 in Ffuncall (nargs=1, args=0x7ffc5d32b140)
> > at eval.c:3174
> > #6 0x0000560a1a7645e9 in call0 (fn=XIL(0x560a5583acf5))
> > at /home/eliz/git/emacs/trunk/src/lisp.h:3490
> > #7 Fhandler_bind_1 (nargs=<optimized out>, args=0x7fe185a46108) at eval.c:1556
> > #8 0x0000560a1a7b672a in exec_byte_code
> > (fun=XIL(0), args_template=455880, nargs=3, args=0x7fe185a46108)
> > at /home/eliz/git/emacs/trunk/src/lisp.h:2234
> > #9 0x0000560a1a762f15 in Ffuncall
> > (nargs=nargs@entry=2, args=args@entry=0x7ffc5d32b2c8) at eval.c:3174
> > #10 0x0000560a1a75df73 in Ffuncall_interactively (nargs=2, args=0x7ffc5d32b2c8)
> > at callint.c:250
> >
> > which AFAIU is part of condition-case processing in
> > with-local-quit(??).
>
> Possible. Hard to tell from that partial backtrace.
A full backtrace below. This is when following the recipe and typing
"ab" after "C-x C-e" to evaluate the loop in *scratch*.
Perhaps you and Stefan run the recipe in a different way, or maybe you
typed a non-ASCII character instead of "ab"?
> > IOW, we quite _after_ while-no-input correctly throws out of the body.
> > the problem is that throwing clears the value of throw-on-input,
> > whereas quit-flag still has the value 'input' that came from
> > while-no-input. So quit-flag is non-nil, but not eq to
> > throw-on-input, and we quit.
>
> That sounds quite unlikely to me. process_quit_flag resets Vquit_flag to
> Qnil, so if we threw out of the body it can't have been set to
> Vthrow_on_input.
See the backtrace below: it clearly shows that quit-flag had the value
'input' when we entered process_quit_flag (and yes, it resets that to
nil, but the original value is in 'flag'). Can you explain the fact
that we 'quit' at the end of process_quit_flag (and more generally
what the backtrace says)?
Thread 1 "emacs" hit Breakpoint 5, quit () at eval.c:1907
1907 return signal_or_quit (Qquit, Qnil, true);
(gdb) bt
#0 quit () at eval.c:1907
#1 process_quit_flag () at eval.c:1861
#2 probably_quit () at eval.c:1869
#3 0x000055db3b9d752c in maybe_quit ()
at /home/eliz/git/emacs/trunk/src/lisp.h:3919
#4 exec_byte_code
(fun=XIL(0), args_template=381256, nargs=2, args=0x7fd33798e1c8)
at bytecode.c:763
#5 0x000055db3b983f15 in Ffuncall (nargs=1, args=0x7ffc4fcd3fd0)
at eval.c:3174
#6 0x000055db3b9855e9 in call0 (fn=XIL(0x55db7984ac2d))
at /home/eliz/git/emacs/trunk/src/lisp.h:3490
#7 Fhandler_bind_1 (nargs=<optimized out>, args=0x7fd33798e108) at eval.c:1556
#8 0x000055db3b9d772a in exec_byte_code
(fun=XIL(0), args_template=381256, nargs=3, args=0x7fd33798e108)
at /home/eliz/git/emacs/trunk/src/lisp.h:2234
#9 0x000055db3b983f15 in Ffuncall
(nargs=nargs@entry=2, args=args@entry=0x7ffc4fcd4158) at eval.c:3174
#10 0x000055db3b97ef73 in Ffuncall_interactively (nargs=2, args=0x7ffc4fcd4158)
at callint.c:250
#11 0x000055db3b983f15 in Ffuncall
(nargs=nargs@entry=3, args=args@entry=0x7ffc4fcd4150) at eval.c:3174
#12 0x000055db3b980b88 in Fcall_interactively
(function=<optimized out>, record_flag=<optimized out>, keys=<optimized out>) at callint.c:789
#13 0x000055db3b9d772a in exec_byte_code
(fun=XIL(0), args_template=381256, nargs=3, args=0x7fd33798e070)
at /home/eliz/git/emacs/trunk/src/lisp.h:2234
#14 0x000055db3b983f15 in Ffuncall
(nargs=nargs@entry=2, args=args@entry=0x7ffc4fcd4450) at eval.c:3174
#15 0x000055db3b8f60e9 in command_loop_1 () at keyboard.c:1545
#16 0x000055db3b982177 in internal_condition_case
(bfun=bfun@entry=0x55db3b8f5b40 <command_loop_1>, handlers=handlers@entry=XIL(0x90), hfun=hfun@entry=0x55db3b8e74f0 <cmd_error>) at eval.c:1690
#17 0x000055db3b8dc91e in command_loop_2 (handlers=handlers@entry=XIL(0x90))
at keyboard.c:1163
#18 0x000055db3b981ff9 in internal_catch
(tag=tag@entry=XIL(0x12660), func=func@entry=0x55db3b8dc8f0 <command_loop_2>, arg=arg@entry=XIL(0x90)) at eval.c:1370
#19 0x000055db3b8dc8b9 in command_loop () at keyboard.c:1141
#20 0x000055db3b8e6fe7 in recursive_edit_1 () at keyboard.c:749
#21 0x000055db3b8e7358 in Frecursive_edit () at keyboard.c:832
#22 0x000055db3b76dbd5 in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:2629
Lisp Backtrace:
"elisp--eval-last-sexp" (0x3798e148)
0x7984ac28 PVEC_CLOSURE
"handler-bind-1" (0x3798e108)
"eval-last-sexp" (0x4fcd4160)
"funcall-interactively" (0x4fcd4158)
"call-interactively" (0x3798e070)
"command-execute" (0x4fcd4458)
(gdb) p globals.f_Vthrow_on_input
$4 = XIL(0)
(gdb) p globals.f_Vquit_flag
$5 = XIL(0)
(gdb) up
#1 process_quit_flag () at eval.c:1861
1861 quit ();
(gdb) p flag
$6 = XIL(0x3dc05570)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$7 = (struct Lisp_Symbol *) 0x55db797abab0
"input"
(gdb)
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 11:11:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 07:11:12 2025 Received: from localhost ([127.0.0.1]:50339 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vBAGl-0002wu-2E for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 07:11:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57966) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vBAGX-0002vm-Ur for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 07:11:07 -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 1vBAGR-0004hR-Bs; Tue, 21 Oct 2025 07:10: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=QLtgv9DWBMIAWgYuA0F+IqEHc1oembGzPLx6ZNmGhSU=; b=ppXIJXJV4TPW /0J952HfQ/bbgjMtIibrLhUAoCZ66A/uDsJw2iq45zlWE1sqV6Yw4XbSfAwYVv1vpwUinkNdRHCyh czxoLbMT+ACDn1jXREl8rfMlsk+uzSJ3d6cdmf3evwk+C4L3JQbRRwVyS/ks1RDuBTIVxKtYxhrzD SK+51NM9BOqZAgKByRCXi38DYf1y9cskHqJ0fvtlrWBKSoGYCrIOInwOF6lWYEJnESXmZEa/T0pue F0mQI/b+NvhS4cgkdJkwyP50XxuW7qGqYytRzdlPbamOg7jYj/Udh/rLhzpKVPFs6ZS8TMKMjE742 jQZR6b08Y9qW2kbhWG3Grw==; Date: Tue, 21 Oct 2025 14:10:45 +0300 Message-Id: <86zf9kwlvu.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <875xc9wftk.fsf@HIDDEN> (message from Pip Cet on Mon, 20 Oct 2025 19:11:19 +0000) Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN> <87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN> <875xc9wftk.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79661 Cc: n142857@HIDDEN, monnier@HIDDEN, 79661 <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: -3.3 (---) > Date: Mon, 20 Oct 2025 19:11:19 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: monnier@HIDDEN, n142857@HIDDEN, 79661 <at> debbugs.gnu.org > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > Where is the call to Fmemq that quits in this case? When I put a > > breakpoint inside 'quit', I don't see Fmemq in the backtrace. > > When I put a breakpoint on 'quit', it doesn't trigger at all, when > following the recipe. Can you add a watchpoint on Vquit_flag and produce > full backtraces of all the times when it changes? I already tried that, but it is impossible to run Emacs after doing so, since the watchpoint triggers too frequently. > > It sounds like with-local-quit (called from while-no-input) somehow > > doesn't work in the TTY case, allowing the 'quit' call after BODY is > > correctly interrupted. What I see in the backtrace is this: > > > > Thread 1 "emacs" hit Breakpoint 4, quit () at eval.c:1907 > > 1907 return signal_or_quit (Qquit, Qnil, true); > > (gdb) bt > > #0 quit () at eval.c:1907 > > #1 process_quit_flag () at eval.c:1861 > > #2 probably_quit () at eval.c:1869 > > #3 0x0000560a1a7b652c in maybe_quit () > > at /home/eliz/git/emacs/trunk/src/lisp.h:3919 > > #4 exec_byte_code > > (fun=XIL(0), args_template=455880, nargs=2, args=0x7fe185a461c8) > > at bytecode.c:763 > > #5 0x0000560a1a762f15 in Ffuncall (nargs=1, args=0x7ffc5d32b140) > > at eval.c:3174 > > #6 0x0000560a1a7645e9 in call0 (fn=XIL(0x560a5583acf5)) > > at /home/eliz/git/emacs/trunk/src/lisp.h:3490 > > #7 Fhandler_bind_1 (nargs=<optimized out>, args=0x7fe185a46108) at eval.c:1556 > > #8 0x0000560a1a7b672a in exec_byte_code > > (fun=XIL(0), args_template=455880, nargs=3, args=0x7fe185a46108) > > at /home/eliz/git/emacs/trunk/src/lisp.h:2234 > > #9 0x0000560a1a762f15 in Ffuncall > > (nargs=nargs@entry=2, args=args@entry=0x7ffc5d32b2c8) at eval.c:3174 > > #10 0x0000560a1a75df73 in Ffuncall_interactively (nargs=2, args=0x7ffc5d32b2c8) > > at callint.c:250 > > > > which AFAIU is part of condition-case processing in > > with-local-quit(??). > > Possible. Hard to tell from that partial backtrace. What else is missing, given that you see the call to handler-bind-1? I can provide fuller backtrace, but the rest is just clutter. > > Maybe this will ring some bells in Stefan's ears. > > Maybe, but there are definitely two bugs that we can fix here: we need > to use assq_no_signal (probably) and memq_no_signal (to be written) in > keyboard.c From where is is_ignored_event called in this scenario? > and someone who understands how this coding stuff works > needs to work out why receiving an incomplete UTF-8 sequence leaves the > terminal->coding structure in a state with carryover bytes, and fails to > resynchronize to the input until the next ASCII character is received. That's irrelevant, I think. The root cause is that we discard input after two bytes, for some reason.
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 06:50:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 02:50:52 2025
Received: from localhost ([127.0.0.1]:49588 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vB6Cq-0003PQ-AJ
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 02:50:52 -0400
Received: from mail-24418.protonmail.ch ([109.224.244.18]:43351)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vB6Cn-0003Ox-60
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 02:50:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1761029442; x=1761288642;
bh=8ILMwDhLFukfhxZIJfRST49ajAwh/fwlTQLhiX/gdMQ=;
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;
b=VjZ39QMNmd1CzIvY6VYNte5ofzVLqLi5IRKHkRfxI7vV+Kgj3Mqw1Ef0xmk8WyOxI
b9GIGHbkCJyTa60aNABhp5Ki+qDEsE8MEJfgJsiWLSL5YPJTBzZseXbmwtlGm8gEgk
mWtAle4aN+FtXX2sr+FXocZnWNzulnEJWSluzmHFWrJWHoMmr+m2UYRpjwyEIM6s4U
EpWwUdEuanFNJyxZS/kK4dSe2HBwZe48Pu0BGIYrmZy00pOfCWgaCfyW7WTf9nitft
l9jSV2XqRlGs609Vdt9p7D3Wxs8dL38x/LlHmBTVIyFhEF1XMEvfIpSBPk+AARlkZV
B9PgRtLkWs6tg==
Date: Tue, 21 Oct 2025 06:50:37 +0000
To: Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
Message-ID: <877bwovjg2.fsf@HIDDEN>
In-Reply-To: <jwvqzuxkwim.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
<jwvv7k9mlep.fsf-monnier+emacs@HIDDEN> <87wm4puxhl.fsf@HIDDEN>
<jwvqzuxkwim.fsf-monnier+emacs@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: aacd1ce762bc5601698f0552cb8029e9ff1cea49
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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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 (-)
"Stefan Monnier" <monnier@HIDDEN> writes:
>>> On my side, I'm thoroughly confused, but I see things like:
>>>
>>> #0 SPECPDL_INDEX () at /home/monnier/src/emacs/main/src/lisp.h:375=
1
>>> #1 inhibit_garbage_collection () at alloc.c:5424
>>> #2 0x0000555e87e51659 in probably_quit () at eval.c:1867
>>> #3 0x0000555e87e5900d in maybe_quit ()
>>> at /home/monnier/src/emacs/main/src/lisp.h:3919
>>> #4 0x0000555e87e59271 in Fmemq (elt=3D..., list=3D...) at fns.c:19=
13
>>> #5 0x0000555e87dc137b in is_ignored_event (event=3Devent@entry=3D0=
x7ffd2535d870)
>>> at keyboard.c:13301
>>> #6 0x0000555e87dcf962 in kbd_buffer_store_buffered_event
>>> (event=3D0x7ffd2535d870,
>>> event@entry=3D0x7ffd2535c7f0, hold_quit=3Dhold_quit@entry=3D0x0=
)
>>> at keyboard.c:3828
>>> #7 0x0000555e87dcf98b in kbd_buffer_store_event_hold
>>> (event=3D0x7ffd2535c7f0, hold_quit=3D0x0)
>>> at /home/monnier/src/emacs/main/src/keyboard.h:510
>>> #8 kbd_buffer_store_event (event=3Devent@entry=3D0x7ffd2535d870)
>>> at keyboard.c:3714
>>> #9 0x0000555e87dd0eb8 in tty_read_avail_input
>>> (terminal=3D<optimized out>, hold_quit=3D<optimized out>) at ke=
yboard.c:8271
>>> #10 0x0000555e87dcfb47 in gobble_input () at keyboard.c:8042
>>> #11 0x0000555e87dcfcc7 in handle_async_input () at keyboard.c:8296
>>> #12 0x0000555e87dcfce0 in process_pending_signals () at keyboard.c:=
8310
>>> #13 0x0000555e87dcfd11 in unblock_input_to (level=3D<optimized out>=
)
>>> at keyboard.c:8325
>>> #14 0x0000555e87e51530 in unwind_to_catch
>>> (catch=3Dcatch@entry=3D0x555ea24eb890, type=3Dtype@entry=3DNONL=
OCAL_EXIT_THROW, value=3D..., value@entry=3D...) at eval.c:1414
>>> #15 0x0000555e87e52a17 in Fthrow (tag=3D..., value=3D..., value@ent=
ry=3D...)
>>> at eval.c:1456
>>> #16 0x0000555e87e52dcf in process_quit_flag ()
>>> at /home/monnier/src/emacs/main/src/lisp.h:1151
>>> #17 0x0000555e87e5169b in probably_quit () at eval.c:1869
>>> [...]
>>
>> That looks my backtrace. It's fixed by the patch I posted, though that
>> is incomplete since other uses of Fmemq and, I think, Fassq in
>> keyboard.c are also unsafe. Plus we need memq_no_signal which still
>> detects circularities, like assq_no_signal does.
>
> You might be right that a `memq_no_signal` is better than `Fmemq` in
> `is_ignored_event` (and similar changes elsewhere, as you suggest),
> I just haven't thought about it. But w.r.t the current problem at hand,
> I think it would just reduce the seriousness of the problem.
>
> IMO the core of the problem is not in this `Fmemq` but in the fact that
> we shouldn't enter `process_pending_signals` at all in the
> above scenario.
I agree.
>> I think our failure to synchronize to bad UTF-8 input is serious and
>> should be fixed, too, though:
>
> No disagreement here, either: just like with the Fmemq thingy, I consider
> it a side-issue (w.r.t the current bug) and have not looked into it at al=
l.
I think both thingies are relevant to the original bug; the UTF-8 thing
less so.
>> If an invalid UTF-8 sequence is followed by a valid UTF-8 character
>> sequence, decode_coding_c_string will return with the leading byte of
>> the second sequence as a carryover.
>
> Why does it do that? Why didn't it return the invalid UTF-8 sequence
> before we even read the first byte of the following (valid) UTF-8 charact=
er?
The sequence is
byte 1: <LEADING OCTET FOR 3-BYTE SEQUENCE>
byte 2: <EXTRA OCTET>
byte 3: <LEADING OCTET FOR 3-BYTE SEQUENCE>
byte 4: <EXTRA OCTET>
byte 5: <EXTRA OCTET>
There's no way to tell the sequence is invalid until we read byte 3.
However, the second time around, the sequence is
byte 1: <EXTRA OCTET>
byte 2: <LEADING OCTET FOR 3-BYTE SEQUENCE>
and there's no reason to read byte 2 at all. That we do seems to me to
be a bug in decode_coding_utf_8 (and there's a similar one in
detect_coding_utf_8!).
If we expect ASCII || LEADING OCTET, and we read an EXTRA OCTET, we
should stop right there. No carryover, just an 8-bit char which will
trigger a resync.
(It seems to be even worse if the first byte we read is 0xfd/0xfe/0xff.
I'll have to look into that, but it might mean we fail to properly
detect UTF-16 BOMs in very short files).
>> diff --git a/src/keyboard.c b/src/keyboard.c
>> index a9cbd107dde..931c3f464ae 100644
>> --- a/src/keyboard.c
>> +++ b/src/keyboard.c
>> @@ -2446,7 +2446,8 @@ #define MAX_ENCODED_BYTES 16
>> =09=09 coding->dst_bytes =3D sizeof dest;
>> =09=09 decode_coding_c_string (coding, src, n, Qnil);
>> =09=09 eassert (coding->produced_char <=3D n);
>> -=09=09 if (coding->produced_char =3D=3D 0)
>> +=09=09 if (coding->produced_char =3D=3D 0
>> +=09=09 || coding->carryover_bytes)
>> =09=09 { /* The encoded sequence is incomplete. */
>> =09=09 if (n < MAX_ENCODED_BYTES) /* Avoid buffer overflow. */
>> =09=09=09continue;=09=09 /* Read on! */
>> @@ -2454,7 +2455,6 @@ #define MAX_ENCODED_BYTES 16
>> =09=09 else
>> =09=09 {
>> =09=09 const unsigned char *p =3D coding->destination;
>> -=09=09 eassert (coding->carryover_bytes =3D=3D 0);
>> =09=09 n =3D 0;
>> =09=09 while (n < coding->produced_char)
>> =09=09=09{
>
> I guess it's OK if there's a good reason for the UTF-8 decoder to behave
> like it does.
Both keyboard.c and coding.c need fixes, I'm afraid.
I'll file a new bug for the UTF-8 thing. It's related only tangentially
and the throw-no-input thing is tricky enough to fix on its own.
Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 21 Oct 2025 06:32:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 21 02:32:40 2025
Received: from localhost ([127.0.0.1]:49514 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vB5vD-0007vw-TP
for submit <at> debbugs.gnu.org; Tue, 21 Oct 2025 02:32:40 -0400
Received: from mail-4316.protonmail.ch ([185.70.43.16]:61509)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vB5vB-0007va-BU
for 79661 <at> debbugs.gnu.org; Tue, 21 Oct 2025 02:32:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1761028351; x=1761287551;
bh=JVDjz+sYMOLbZTrTXN7GsifZCQobnuPxhAZ1BtiGkN8=;
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;
b=oPbBk9XEKrU77bQTllQEeJjHvLmmNx/1v1VHX5wBVVe0XsTgSYMJrOvSTNe97cD6i
FeXi1p09won8NxgySVzQ1OHjtFivrJJeJtQo7izBb95Br9jUqlU3C5E/+PzjB6ZbaA
TZYDMPDKHmc/ohVOpEUHpqxdHFtnWAxNO6/EYAsZcO2V8h8Sii/wqi1NEkjSaciIn6
jWh17t6DkOyxa/wUa8z7jpnTAU+cZ+WuDvc45fTBNxZ9fEAefJecHbl+jlWbpDyAkU
SStmlIbnRECVxRor9TJr1S5BCBq2ceuMw1UCisHca6uDJ/WeGqY6YBuGvxFPwg9ajD
ok7TQnKWIGAFg==
Date: Tue, 21 Oct 2025 06:32:24 +0000
To: Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
Message-ID: <87cy6gvkaf.fsf@HIDDEN>
In-Reply-To: <jwvldl5kvi5.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
<jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
<jwva51lmif6.fsf-monnier+emacs@HIDDEN> <87ldl5uui2.fsf@HIDDEN>
<jwvldl5kvi5.fsf-monnier+emacs@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: fd31b80d7aa23f2a3da892d21ec98c178f4dbc63
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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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 (-)
"Stefan Monnier" <monnier@HIDDEN> writes:
>> Does this change behavior in any way?
>>
>> diff --git a/src/keyboard.c b/src/keyboard.c
>> index a9cbd107dde..4fe0d9f836f 100644
>> --- a/src/keyboard.c
>> +++ b/src/keyboard.c
>> @@ -8318,6 +8318,8 @@ process_pending_signals (void)
>> void
>> unblock_input_to (int level)
>> {
>> + if (interrupt_input_blocked =3D=3D level)
>> + return;
>> interrupt_input_blocked =3D level;
>> if (level =3D=3D 0)
>> {
>
> That seems to help, yes. I'm not able to reproduce the problem here
> after installing it.
> I don't understand enough of what it does to be sure that it would fix
> it in all cases, OTOH (nor whether it's safe for `totally_unblock_input`)=
.
I don't think it fixes anything! I was only trying to understand this
(third!) problem, not suggesting a solution, sorry I didn't make that
clearer.
I cannot think of a simple fix that preserves the entire throw-on-input
API as documented.
As long as while-no-input is the only user and it continues using fresh
uninterned symbols, we could keep track of the last tag we set
Vquit_flag to, and throw to each tag at most once. That would make the
Lisp-side API even harder to use correctly.
Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 23:33:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 19:33:11 2025
Received: from localhost ([127.0.0.1]:48217 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vAzNH-0007k9-0T
for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 19:33:11 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7497)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vAzNE-0007jL-Dr
for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 19:33:08 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9ECBF44176E;
Mon, 20 Oct 2025 19:33:02 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761003181;
bh=BqeS2yCe8kabAZowMBJ2k+aT0lysIGx1RZ8ioJ/k1CA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=UDx2wfrNIvXES8bwryR7w9LYJCGe3hxd0MoWUf4ii0iOdbqJTy+sSjqlYhos3eKx4
0wh6mxrTvnLCkv/GApLWig+2u+ckE/IUxvtOAlvi+yD9q9/AqHh9jed3SHnJj1loHH
iEVZ9FNPfQssBelSVW/M7luytJkoi1Fd0eXB/QgIEo0dv8IusIEp9DT8cjuienASQb
VsiQPRzKSKE0EWoecvaJC2ad4VEys8QIu1qnJXgMoXuTE6vpuhIBJiOHsSsASHMIFC
RC0cOUTPa9TK3HnAtTyfSU48sKH2g7OwrvYOyVa6hYk83TzY1/eh3bNGSb+jD/7Iu+
Wsy0IdJqODHEw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 87F5E4403D0;
Mon, 20 Oct 2025 19:33:01 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 12CA112039E;
Mon, 20 Oct 2025 19:32:59 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <87ldl5uui2.fsf@HIDDEN>
Message-ID: <jwvldl5kvi5.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
<jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
<jwva51lmif6.fsf-monnier+emacs@HIDDEN>
<87ldl5uui2.fsf@HIDDEN>
Date: Mon, 20 Oct 2025 19:32:56 -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.069 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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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: -3.3 (---)
> Does this change behavior in any way?
>
> diff --git a/src/keyboard.c b/src/keyboard.c
> index a9cbd107dde..4fe0d9f836f 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -8318,6 +8318,8 @@ process_pending_signals (void)
> void
> unblock_input_to (int level)
> {
> + if (interrupt_input_blocked == level)
> + return;
> interrupt_input_blocked = level;
> if (level == 0)
> {
That seems to help, yes. I'm not able to reproduce the problem here
after installing it.
I don't understand enough of what it does to be sure that it would fix
it in all cases, OTOH (nor whether it's safe for `totally_unblock_input`).
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 23:16:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 19:16:35 2025
Received: from localhost ([127.0.0.1]:48139 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vAz7C-00062Z-Rl
for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 19:16:35 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29388)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vAz7A-000622-MT
for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 19:16:33 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AC0C81002F0;
Mon, 20 Oct 2025 19:16:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1761002185;
bh=wKBgD6ntNcSaP0YvCvnf3hB3MABw3YQjwmgLMX+hsP8=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=dWOYVVe2CcrUggIuHGEsvCyDDvjS0fccmKMK5nn23TJZJ67/tmeeLu+mO0h8YAqo+
4IBADYKC2XVB/YbPB7RC4bawE27yFTBsaJ40StBPAsDNwmSfW+0PBf9Wh4owjdSncP
ViyC0e/WZ3GPeu3rF4B6TGQi+4kBRdDBsg/YSkHoNwnUJ1aoHlXYJMStg8RT2xTu9B
lBrQTb9MqOLplWCcR4umfacRNtPphkjVbKcXhbG/Xa9iBGeHqupugxQdmHGLUZIUGd
DoYOqLVyRtW63kaBNmL34giuB+dafk2ZjCnkoHm2+AhgYmqQzOYzMU9jRYCbARcz5Y
DFELP5brZeGfw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 95E4310013E;
Mon, 20 Oct 2025 19:16:25 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 18A5812021A;
Mon, 20 Oct 2025 19:16:23 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <87wm4puxhl.fsf@HIDDEN>
Message-ID: <jwvqzuxkwim.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
<jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
<87wm4puxhl.fsf@HIDDEN>
Date: Mon, 20 Oct 2025 19:16:20 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.070 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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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: -3.3 (---)
>> On my side, I'm thoroughly confused, but I see things like:
>>
>> #0 SPECPDL_INDEX () at /home/monnier/src/emacs/main/src/lisp.h:3751
>> #1 inhibit_garbage_collection () at alloc.c:5424
>> #2 0x0000555e87e51659 in probably_quit () at eval.c:1867
>> #3 0x0000555e87e5900d in maybe_quit ()
>> at /home/monnier/src/emacs/main/src/lisp.h:3919
>> #4 0x0000555e87e59271 in Fmemq (elt=..., list=...) at fns.c:1913
>> #5 0x0000555e87dc137b in is_ignored_event (event=event@entry=0x7ffd2535d870)
>> at keyboard.c:13301
>> #6 0x0000555e87dcf962 in kbd_buffer_store_buffered_event
>> (event=0x7ffd2535d870,
>> event@entry=0x7ffd2535c7f0, hold_quit=hold_quit@entry=0x0)
>> at keyboard.c:3828
>> #7 0x0000555e87dcf98b in kbd_buffer_store_event_hold
>> (event=0x7ffd2535c7f0, hold_quit=0x0)
>> at /home/monnier/src/emacs/main/src/keyboard.h:510
>> #8 kbd_buffer_store_event (event=event@entry=0x7ffd2535d870)
>> at keyboard.c:3714
>> #9 0x0000555e87dd0eb8 in tty_read_avail_input
>> (terminal=<optimized out>, hold_quit=<optimized out>) at keyboard.c:8271
>> #10 0x0000555e87dcfb47 in gobble_input () at keyboard.c:8042
>> #11 0x0000555e87dcfcc7 in handle_async_input () at keyboard.c:8296
>> #12 0x0000555e87dcfce0 in process_pending_signals () at keyboard.c:8310
>> #13 0x0000555e87dcfd11 in unblock_input_to (level=<optimized out>)
>> at keyboard.c:8325
>> #14 0x0000555e87e51530 in unwind_to_catch
>> (catch=catch@entry=0x555ea24eb890, type=type@entry=NONLOCAL_EXIT_THROW, value=..., value@entry=...) at eval.c:1414
>> #15 0x0000555e87e52a17 in Fthrow (tag=..., value=..., value@entry=...)
>> at eval.c:1456
>> #16 0x0000555e87e52dcf in process_quit_flag ()
>> at /home/monnier/src/emacs/main/src/lisp.h:1151
>> #17 0x0000555e87e5169b in probably_quit () at eval.c:1869
>> [...]
>
> That looks my backtrace. It's fixed by the patch I posted, though that
> is incomplete since other uses of Fmemq and, I think, Fassq in
> keyboard.c are also unsafe. Plus we need memq_no_signal which still
> detects circularities, like assq_no_signal does.
You might be right that a `memq_no_signal` is better than `Fmemq` in
`is_ignored_event` (and similar changes elsewhere, as you suggest),
I just haven't thought about it. But w.r.t the current problem at hand,
I think it would just reduce the seriousness of the problem.
IMO the core of the problem is not in this `Fmemq` but in the fact that
we shouldn't enter `process_pending_signals` at all in the
above scenario.
> I think our failure to synchronize to bad UTF-8 input is serious and
> should be fixed, too, though:
No disagreement here, either: just like with the Fmemq thingy, I consider
it a side-issue (w.r.t the current bug) and have not looked into it at all.
> If an invalid UTF-8 sequence is followed by a valid UTF-8 character
> sequence, decode_coding_c_string will return with the leading byte of
> the second sequence as a carryover.
Why does it do that? Why didn't it return the invalid UTF-8 sequence
before we even read the first byte of the following (valid) UTF-8 character?
> diff --git a/src/keyboard.c b/src/keyboard.c
> index a9cbd107dde..931c3f464ae 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -2446,7 +2446,8 @@ #define MAX_ENCODED_BYTES 16
> coding->dst_bytes = sizeof dest;
> decode_coding_c_string (coding, src, n, Qnil);
> eassert (coding->produced_char <= n);
> - if (coding->produced_char == 0)
> + if (coding->produced_char == 0
> + || coding->carryover_bytes)
> { /* The encoded sequence is incomplete. */
> if (n < MAX_ENCODED_BYTES) /* Avoid buffer overflow. */
> continue; /* Read on! */
> @@ -2454,7 +2455,6 @@ #define MAX_ENCODED_BYTES 16
> else
> {
> const unsigned char *p = coding->destination;
> - eassert (coding->carryover_bytes == 0);
> n = 0;
> while (n < coding->produced_char)
> {
I guess it's OK if there's a good reason for the UTF-8 decoder to behave
like it does.
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 21:37:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 17:37:22 2025
Received: from localhost ([127.0.0.1]:47850 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vAxZB-0006zn-NN
for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 17:37:22 -0400
Received: from mail-4322.protonmail.ch ([185.70.43.22]:10353)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vAxZ8-0006z4-IW
for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 17:37:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1760996231; x=1761255431;
bh=wFv549XPgvcC+ITN6YomPIcJKtrvx+wv/sGF+s7aYqM=;
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;
b=Xn/UzTNfe9gWlk7/0MGfHJMD5H6HYLgO47bodjXNrCySbSRhGNMbinehWoABq6y2O
nMFh6BL1VKRz0JjpfWBfBInArs5MVv9WTsN88htuuj9nqwQGk5KsM/z31Dp+dWzmWx
azyVq0xfc+T3W+U33FyWood6z5D7h70ho02ch7baIW2Q2w0f0mzW/DXExB+vHTA+1t
TBeyIT1YLoiICa9Et+uPnosNizSLjUQ230O+MhWDPMHXZWDiJ1n4SKQvF4gvtfvzze
gzn50JJGR/mIEbA1+Nk7gIRuLcvjBLGhK4r7A12ahIDrIBsGGglGCN9Qb7nYyrZyZ5
tRRwvS/rBq2iw==
Date: Mon, 20 Oct 2025 21:37:08 +0000
To: Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
Message-ID: <87ldl5uui2.fsf@HIDDEN>
In-Reply-To: <jwva51lmif6.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
<jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
<jwva51lmif6.fsf-monnier+emacs@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: d3a8eb4ab31992e7f550324e29c2dc40fef919ce
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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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 (-)
"Stefan Monnier" <monnier@HIDDEN> writes:
>> Tho, AFAICT at that point `quit-flag` is nil, so maybe it's not an
>> issue, but it does make debugging trickier.
>
> According to fprintf we have the following sequence of events:
>
> Setting Vquit_flag =3D Vthrow_on_input
> setting Vquit_flag =3D Qnil in process_quit_flag
> Fthrow (Vthrow_on_input, Qt)
> entering unwind_to_catch...
> Setting Vquit_flag =3D Vthrow_on_input
So I guess unblock_input_to calls gobble_input, which calls
kbd_buffer_store_buffered_event, which sets quit-flag?
That would explain the timing issue: on my system, the second and third
byte don't arrive in time to set pending_signals before we check it in
unblock_input_to. On your systems, it appears to.
Does this change behavior in any way?
diff --git a/src/keyboard.c b/src/keyboard.c
index a9cbd107dde..4fe0d9f836f 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -8318,6 +8318,8 @@ process_pending_signals (void)
void
unblock_input_to (int level)
{
+ if (interrupt_input_blocked =3D=3D level)
+ return;
interrupt_input_blocked =3D level;
if (level =3D=3D 0)
{
Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 21:11:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 17:11:09 2025
Received: from localhost ([127.0.0.1]:47777 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vAx9p-0004sY-Io
for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 17:11:09 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30841)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vAx9o-0004sK-CO
for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 17:11:08 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 35465441763;
Mon, 20 Oct 2025 17:11:02 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1760994660;
bh=eCcaiUs4gUoSsamF2CEXccDazmht7SsSpFmDSZoAr88=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=h+EitDn46LMSFvUJZDH7jnfnajVaFLuNycWaGyHnNFeQ7VDTWPFjJiR4H4xN3hnR+
gE3NJkh4HcdqMSN8eA0PKRsg1Ve2paFqYXfxapD+X2k8qnDnCBOA96A1lmaTMKGwd/
l0TVDPOPOwxuNrhvCH6FX+0dxp5SzCJCRS94GZI9PY57fkDh8SePl9OC32BeABnpAT
CPI++hP/jroP2pqnqPwjzfnY0lSTgbKZjFqLad1ybh+UZRmBN4jIJ+B7z6yq9gJKxL
UACwgYywhoFlmYjm5vO2Oo17uHrP/7pSZSF7KzE7eUyEK3uxkLGBhHsAJBItfvQ+Tc
SF2AtnQGVuO/Q==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B5AEB441760;
Mon, 20 Oct 2025 17:11:00 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3A06C12026A;
Mon, 20 Oct 2025 17:10:58 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
Message-ID: <jwva51lmif6.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
<jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
Date: Mon, 20 Oct 2025 17:10:55 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.049 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: 79661
Cc: n142857@HIDDEN, Pip Cet <pipcet@HIDDEN>, 79661 <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: -3.3 (---)
> Tho, AFAICT at that point `quit-flag` is nil, so maybe it's not an
> issue, but it does make debugging trickier.
According to fprintf we have the following sequence of events:
Setting Vquit_flag = Vthrow_on_input
setting Vquit_flag = Qnil in process_quit_flag
Fthrow (Vthrow_on_input, Qt)
entering unwind_to_catch...
Setting Vquit_flag = Vthrow_on_input
unwind_to_catch starting unbind_to loop...
...sys_longjmp
setting Vquit_flag = Qnil in process_quit_flag
entering quit ()
entering unwind_to_catch...
unwind_to_catch starting unbind_to loop...
...sys_longjmp
setting Vquit_flag = Qnil in process_quit_flag
entering quit ()
entering unwind_to_catch...
unwind_to_catch starting unbind_to loop...
...sys_longjmp
Entering Fcommand_error_default_function...
- Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 20:32:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 16:32:52 2025
Received: from localhost ([127.0.0.1]:47688 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vAwYl-0007qH-MR
for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 16:32:52 -0400
Received: from mail-24416.protonmail.ch ([109.224.244.16]:31633)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vAwYj-0007p4-7X
for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 16:32:50 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1760992361; x=1761251561;
bh=8W8fA08ubdt67lO7oAaK3kR7w7NUzgyQ0m+Zzl2zOOU=;
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;
b=KsZ07ZlwaYHXPpxqNMF2837B6S/ERk6r359vHM155VpFOZ/VVBruvLvx1K2XOjIqf
4QcKighZ0BH3wnm+ti7HaWPwoWXBWgiT2Z7DJ+w2jfjxFBlwpUyf4ES596BoH+CLIK
Qtr/n28eU0nom7FdO1qcb+2+CnDqe+y+qci8gIaF5hQvuudYp7FQIOFhpLWIWk/99T
qfKVm3LPAYYS6HygDbJG4ZOsAefX8M6O7wWY6CBl2DJ7uxjGaICOcyfrRyBcQt45Sj
Zx7FrDoCeDu4DxWBbsDoQT66UDo5aPqbOaQXsHMVNe/A0E9bCv/JAQTc3npKGcDcna
FI0yISkLpUWRw==
Date: Mon, 20 Oct 2025 20:32:37 +0000
To: Stefan Monnier <monnier@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
Message-ID: <87wm4puxhl.fsf@HIDDEN>
In-Reply-To: <jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
<jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 9a1c28392f792c6cb67ca5eea8b9aad1382f1096
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: 79661
Cc: n142857@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79661 <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 (-)
"Stefan Monnier" <monnier@HIDDEN> writes:
>>> while-no-input "quits" don't go through "quit", they're handled by
>>> "process_quit_flag".
>>
>> Look at the backtrace I posted: it tells a very different story. Not
>> sure why, maybe we are looking at two separate issues. But I cannot
>> see Fmemq anywhere when I repeat the recipe in a TTY session on
>> GNU/Linux.
>
> On my side, I'm thoroughly confused, but I see things like:
>
> #0 SPECPDL_INDEX () at /home/monnier/src/emacs/main/src/lisp.h:3751
> #1 inhibit_garbage_collection () at alloc.c:5424
> #2 0x0000555e87e51659 in probably_quit () at eval.c:1867
> #3 0x0000555e87e5900d in maybe_quit ()
> at /home/monnier/src/emacs/main/src/lisp.h:3919
> #4 0x0000555e87e59271 in Fmemq (elt=3D..., list=3D...) at fns.c:1913
> #5 0x0000555e87dc137b in is_ignored_event (event=3Devent@entry=3D0x7=
ffd2535d870)
> at keyboard.c:13301
> #6 0x0000555e87dcf962 in kbd_buffer_store_buffered_event
> (event=3D0x7ffd2535d870,
> event@entry=3D0x7ffd2535c7f0, hold_quit=3Dhold_quit@entry=3D0x0)
> at keyboard.c:3828
> #7 0x0000555e87dcf98b in kbd_buffer_store_event_hold
> (event=3D0x7ffd2535c7f0, hold_quit=3D0x0)
> at /home/monnier/src/emacs/main/src/keyboard.h:510
> #8 kbd_buffer_store_event (event=3Devent@entry=3D0x7ffd2535d870)
> at keyboard.c:3714
> #9 0x0000555e87dd0eb8 in tty_read_avail_input
> (terminal=3D<optimized out>, hold_quit=3D<optimized out>) at keyb=
oard.c:8271
> #10 0x0000555e87dcfb47 in gobble_input () at keyboard.c:8042
> #11 0x0000555e87dcfcc7 in handle_async_input () at keyboard.c:8296
> #12 0x0000555e87dcfce0 in process_pending_signals () at keyboard.c:83=
10
> #13 0x0000555e87dcfd11 in unblock_input_to (level=3D<optimized out>)
> at keyboard.c:8325
> #14 0x0000555e87e51530 in unwind_to_catch
> (catch=3Dcatch@entry=3D0x555ea24eb890, type=3Dtype@entry=3DNONLOC=
AL_EXIT_THROW, value=3D..., value@entry=3D...) at eval.c:1414
> #15 0x0000555e87e52a17 in Fthrow (tag=3D..., value=3D..., value@entry=
=3D...)
> at eval.c:1456
> #16 0x0000555e87e52dcf in process_quit_flag ()
> at /home/monnier/src/emacs/main/src/lisp.h:1151
> #17 0x0000555e87e5169b in probably_quit () at eval.c:1869
> [...]
That looks my backtrace. It's fixed by the patch I posted, though that
is incomplete since other uses of Fmemq and, I think, Fassq in
keyboard.c are also unsafe.
Plus we need memq_no_signal which still detects circularities, like
assq_no_signal does.
> Tho, AFAICT at that point `quit-flag` is nil, so maybe it's not an
> issue, but it does make debugging trickier.
If pending_signals is false, quit-flag must be non-nil or we wouldn't
have entered probably_quit.
I think our failure to synchronize to bad UTF-8 input is serious and
should be fixed, too, though:
From b369644bd2724e4246ae3a002badb25e5f910f8f Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Mon, 20 Oct 2025 20:03:14 +0000
Subject: [PATCH] Don't assume UTF-8 has no carryover bytes (bug#79661)
If an invalid UTF-8 sequence is followed by a valid UTF-8 character
sequence, decode_coding_c_string will return with the leading byte of
the second sequence as a carryover. The old code dropped the
carryover, so we'd fail to synchronize with the terminal until the
next ASCII byte was received.
* src/keyboard.c (read_decoded_event_from_main_queue): Continue
reading while there are carryover bytes (which means only invalid
sequences have been received). Drop assertion.
---
src/keyboard.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/keyboard.c b/src/keyboard.c
index a9cbd107dde..931c3f464ae 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2446,7 +2446,8 @@ #define MAX_ENCODED_BYTES 16
=09=09 coding->dst_bytes =3D sizeof dest;
=09=09 decode_coding_c_string (coding, src, n, Qnil);
=09=09 eassert (coding->produced_char <=3D n);
-=09=09 if (coding->produced_char =3D=3D 0)
+=09=09 if (coding->produced_char =3D=3D 0
+=09=09 || coding->carryover_bytes)
=09=09 { /* The encoded sequence is incomplete. */
=09=09 if (n < MAX_ENCODED_BYTES) /* Avoid buffer overflow. */
=09=09=09continue;=09=09 /* Read on! */
@@ -2454,7 +2455,6 @@ #define MAX_ENCODED_BYTES 16
=09=09 else
=09=09 {
=09=09 const unsigned char *p =3D coding->destination;
-=09=09 eassert (coding->carryover_bytes =3D=3D 0);
=09=09 n =3D 0;
=09=09 while (n < coding->produced_char)
=09=09=09{
--=20
2.51.0
This is a minimal change; the behavior is somewhat undesirable as the
incomplete sequences will turn into eight-bit characters, but they will
only be handled once a valid following character is received. We could
do better and handle the eight-bit characters when the next byte is
received, but it'd require keeping a carryover buffer somewhere else.
Alternatively, we could drop invalid codes rather than producing
eight-bit characters for them, in this specific instance.
> [ Side note: maybe this is fundamentally OK and unrelated to the problem
> at hand, but I believe we should inhibit all forms of quit-processing
> while unwinding the stack (this is needed to avoid inconsistent states
> due to some unwind form (meant to restore a consistent state) having
> been interrupted by a quit). ]
Quit flag handling desperately needs some TLC: in the Vinhibit_quit &&
Vquit_flag case, we enter probably_quit a lot, inhibiting garbage
collection each time before deciding we don't need to do anything after
all. This makes stepping through code in that situation somewhat
painful.
Also, fundamentally, there should be a single flag for pending_signals
and the quit flag (making maybe_quit just a tiny bit cheaper).
My proposal was a "real" quit flag in C, with a variable watcher on
quit-flag setting the real quit flag only if inhibit-quit is nil, and
another variable watcher on inhibit-quit, also setting the real quit
flag if appropriate.
Ultimately, there should be a single place which clears the real quit
flag.
But it wasn't well-received. "]", I guess.
Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 19:30:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 15:30:45 2025
Received: from localhost ([127.0.0.1]:47597 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vAvaf-0004CX-30
for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 15:30:45 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44266)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vAvac-0004C1-PN
for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 15:30:43 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B596E441535;
Mon, 20 Oct 2025 15:30:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1760988630;
bh=AdJu6tia2wg63Vf4dIWN2rXaoFIh1wkz/HTen83BODA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=W9o4/gQrxVnyHsfah8ylvraVzKuYlzb8xKGGkyxNnQ5sUzYaOCgsV6/UrJYe4NKAK
rPvV6y66wWOS4frfJT2EPkDGmWaPrY+sM156/H5MB2q3F/ofn+wVrc+t/Uz1ZQtWsa
1j4mFlO5a5TcaRHKvuu9pArxq67W5nAWBEbVSV5MZBA/j216xwVvJ2OrTZt+RW9SNV
jdd11ZeHDXmGEuCrhLTI75F9wKxIHl/EUJiZKASS4rvpdYRsqHJUBWpfEy2Oyy9sb3
9HUfvonXb88nDvdf4oP9pk940Mv29puUfE7cC3Cy04H5s5mpAgL9zcUkY5zBTA57GJ
X8V+o9TGSc2sQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D96BC4406DC;
Mon, 20 Oct 2025 15:30:30 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 368C71202D5;
Mon, 20 Oct 2025 15:30:29 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <86347dxwxv.fsf@HIDDEN>
Message-ID: <jwvv7k9mlep.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN>
<87bjm1wizi.fsf@HIDDEN> <86347dxwxv.fsf@HIDDEN>
Date: Mon, 20 Oct 2025 15:30:25 -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.052 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: 79661
Cc: n142857@HIDDEN, Pip Cet <pipcet@HIDDEN>, 79661 <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: -3.3 (---)
>> while-no-input "quits" don't go through "quit", they're handled by
>> "process_quit_flag".
>
> Look at the backtrace I posted: it tells a very different story. Not
> sure why, maybe we are looking at two separate issues. But I cannot
> see Fmemq anywhere when I repeat the recipe in a TTY session on
> GNU/Linux.
On my side, I'm thoroughly confused, but I see things like:
#0 SPECPDL_INDEX () at /home/monnier/src/emacs/main/src/lisp.h:3751
#1 inhibit_garbage_collection () at alloc.c:5424
#2 0x0000555e87e51659 in probably_quit () at eval.c:1867
#3 0x0000555e87e5900d in maybe_quit ()
at /home/monnier/src/emacs/main/src/lisp.h:3919
#4 0x0000555e87e59271 in Fmemq (elt=..., list=...) at fns.c:1913
#5 0x0000555e87dc137b in is_ignored_event (event=event@entry=0x7ffd2535d870)
at keyboard.c:13301
#6 0x0000555e87dcf962 in kbd_buffer_store_buffered_event
(event=0x7ffd2535d870,
event@entry=0x7ffd2535c7f0, hold_quit=hold_quit@entry=0x0)
at keyboard.c:3828
#7 0x0000555e87dcf98b in kbd_buffer_store_event_hold
(event=0x7ffd2535c7f0, hold_quit=0x0)
at /home/monnier/src/emacs/main/src/keyboard.h:510
#8 kbd_buffer_store_event (event=event@entry=0x7ffd2535d870)
at keyboard.c:3714
#9 0x0000555e87dd0eb8 in tty_read_avail_input
(terminal=<optimized out>, hold_quit=<optimized out>) at keyboard.c:8271
#10 0x0000555e87dcfb47 in gobble_input () at keyboard.c:8042
#11 0x0000555e87dcfcc7 in handle_async_input () at keyboard.c:8296
#12 0x0000555e87dcfce0 in process_pending_signals () at keyboard.c:8310
#13 0x0000555e87dcfd11 in unblock_input_to (level=<optimized out>)
at keyboard.c:8325
#14 0x0000555e87e51530 in unwind_to_catch
(catch=catch@entry=0x555ea24eb890, type=type@entry=NONLOCAL_EXIT_THROW, value=..., value@entry=...) at eval.c:1414
#15 0x0000555e87e52a17 in Fthrow (tag=..., value=..., value@entry=...)
at eval.c:1456
#16 0x0000555e87e52dcf in process_quit_flag ()
at /home/monnier/src/emacs/main/src/lisp.h:1151
#17 0x0000555e87e5169b in probably_quit () at eval.c:1869
[...]
Tho, AFAICT at that point `quit-flag` is nil, so maybe it's not an
issue, but it does make debugging trickier.
[ Side note: maybe this is fundamentally OK and unrelated to the problem
at hand, but I believe we should inhibit all forms of quit-processing
while unwinding the stack (this is needed to avoid inconsistent states
due to some unwind form (meant to restore a consistent state) having
been interrupted by a quit). ]
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 19:11:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 15:11:35 2025 Received: from localhost ([127.0.0.1]:47544 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vAvI7-0002cW-7I for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 15:11:35 -0400 Received: from mail-10629.protonmail.ch ([79.135.106.29]:14589) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vAvI3-0002cD-SH for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 15:11:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1760987484; x=1761246684; bh=XLP9sq9iycEdtcx07aVtsHyRaicHt5H6QBu5erKmMXc=; 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; b=VXK8uYRyjGmNG7crTKWsep7IU3izye3lUkQVMp0ImQQD6D6JCoBFyd540hthpQv74 1iiHz07LEYNtEn1jIWhOqpZXX29FQADV5wjPYSlF5c6DDVWrVpL2HKF4uTQs5wO1GC GstTeszvXo8FERr1Weujbfi5Boq8W0keT1S8dGBy2cE2zljgTUvDRBLQrrp3bX30Gk Cw0O9fKbvmaUtUVho3fIq+Ca0mLyWKkktA7CPKn5GEndF47pe/9L44Sp+9FSLM+mTv KNOcCGgsYpGU8CW0DXN2Z4rXHT+9Z9NbZggubwwX9hLDUh7DPDQExDV9u/Zpx07TXR AslrizOkwNd+w== Date: Mon, 20 Oct 2025 19:11:19 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY Message-ID: <875xc9wftk.fsf@HIDDEN> In-Reply-To: <867bwpy1gu.fsf@HIDDEN> References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN> <87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b6a5d14d531483b289b4b798528300e5e1bfdb06 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: 79661 Cc: n142857@HIDDEN, monnier@HIDDEN, 79661 <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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Mon, 20 Oct 2025 15:40:59 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> >> This helps here, but I'm not sure it's the same bug: >> >> >From a9ad266ddbf02a5f309f40ff64f7407309ab7dd5 Mon Sep 17 00:00:00 2001 >> From: Pip Cet <pipcet@HIDDEN> >> Date: Mon, 20 Oct 2025 15:35:08 +0000 >> Subject: [PATCH] Avoid quitting in keyboard_store_buffered_event (bug#79= 661) >> >> * src/keyboard.c (is_ignored_event): Use 'memq_no_quit', not 'Fmemq'. >> --- >> src/keyboard.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/keyboard.c b/src/keyboard.c >> index e37f8ec7cdc..f525eff8cab 100644 >> --- a/src/keyboard.c >> +++ b/src/keyboard.c >> @@ -13375,7 +13375,7 @@ is_ignored_event (union buffered_input_event *ev= ent) >> default: ignore_event =3D Qnil; break; >> } >> >> - return !NILP (Fmemq (ignore_event, Vwhile_no_input_ignore_events)); >> + return !NILP (memq_no_quit (ignore_event, Vwhile_no_input_ignore_even= ts)); >> } >> >> static uint8_t >> -- >> 2.51.0 >> >> Fairly obvious explanation: Fmemq quits, we really shouldn't quit in the >> middle of handling terminal input. > > Where is the call to Fmemq that quits in this case? When I put a > breakpoint inside 'quit', I don't see Fmemq in the backtrace. When I put a breakpoint on 'quit', it doesn't trigger at all, when following the recipe. Can you add a watchpoint on Vquit_flag and produce full backtraces of all the times when it changes? > It sounds like with-local-quit (called from while-no-input) somehow > doesn't work in the TTY case, allowing the 'quit' call after BODY is > correctly interrupted. What I see in the backtrace is this: > > Thread 1 "emacs" hit Breakpoint 4, quit () at eval.c:1907 > 1907 return signal_or_quit (Qquit, Qnil, true); > (gdb) bt > #0 quit () at eval.c:1907 > #1 process_quit_flag () at eval.c:1861 > #2 probably_quit () at eval.c:1869 > #3 0x0000560a1a7b652c in maybe_quit () > at /home/eliz/git/emacs/trunk/src/lisp.h:3919 > #4 exec_byte_code > (fun=3DXIL(0), args_template=3D455880, nargs=3D2, args=3D0x7fe185a4= 61c8) > at bytecode.c:763 > #5 0x0000560a1a762f15 in Ffuncall (nargs=3D1, args=3D0x7ffc5d32b140) > at eval.c:3174 > #6 0x0000560a1a7645e9 in call0 (fn=3DXIL(0x560a5583acf5)) > at /home/eliz/git/emacs/trunk/src/lisp.h:3490 > #7 Fhandler_bind_1 (nargs=3D<optimized out>, args=3D0x7fe185a46108) at= eval.c:1556 > #8 0x0000560a1a7b672a in exec_byte_code > (fun=3DXIL(0), args_template=3D455880, nargs=3D3, args=3D0x7fe185a4= 6108) > at /home/eliz/git/emacs/trunk/src/lisp.h:2234 > #9 0x0000560a1a762f15 in Ffuncall > (nargs=3Dnargs@entry=3D2, args=3Dargs@entry=3D0x7ffc5d32b2c8) at ev= al.c:3174 > #10 0x0000560a1a75df73 in Ffuncall_interactively (nargs=3D2, args=3D0x7= ffc5d32b2c8) > at callint.c:250 > > which AFAIU is part of condition-case processing in > with-local-quit(??). Possible. Hard to tell from that partial backtrace. > IOW, we quite _after_ while-no-input correctly throws out of the body. > the problem is that throwing clears the value of throw-on-input, > whereas quit-flag still has the value 'input' that came from > while-no-input. So quit-flag is non-nil, but not eq to > throw-on-input, and we quit. That sounds quite unlikely to me. process_quit_flag resets Vquit_flag to Qnil, so if we threw out of the body it can't have been set to Vthrow_on_input. > Maybe this will ring some bells in Stefan's ears. Maybe, but there are definitely two bugs that we can fix here: we need to use assq_no_signal (probably) and memq_no_signal (to be written) in keyboard.c, and someone who understands how this coding stuff works needs to work out why receiving an incomplete UTF-8 sequence leaves the terminal->coding structure in a state with carryover bytes, and fails to resynchronize to the input until the next ASCII character is received. Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 18:14:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 14:14:34 2025 Received: from localhost ([127.0.0.1]:47297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vAuOv-0005z0-Rt for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 14:14:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59612) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vAuOs-0005yV-1w for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 14:14:31 -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 1vAuOl-0005su-MG; Mon, 20 Oct 2025 14:14:23 -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=kbhOoDXvAWoQYeIJd0/p0HQ45SGopNzJRe1dHwResd0=; b=KsgO+eca7liY mSYiVab/DiIjeHuDo1RCpP/iH/0LvSNojrr/CJPUe+HqvKYk6JS0+1imXe+/gpvDHvD8MmjV60wnE b8SujyTHgjDk6E8J0UK8IFyHdyxn3UnwSlKsAVPZ0D3cfnxgY6MquTiP+HCQ3mBGRSGvpAefs95Rj HlLHapRXkR5GUnoBc47Y8FygBOAjqM1cdAsp1uuA0UzIuFUrxpREc+sTvxdc8MDgYnGOpUtMQ4Bfc afh5t88kBDSLibU30frXrtIQpDLHvjmGf78mMGuNNPRayjudW4bvXGIWw58c2od1/gsAreG+0+apJ fRXxvrGqvCQL631cx1sLjg==; Date: Mon, 20 Oct 2025 21:14:20 +0300 Message-Id: <86347dxwxv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87bjm1wizi.fsf@HIDDEN> (message from Pip Cet on Mon, 20 Oct 2025 18:02:56 +0000) Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN> <87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN> <87bjm1wizi.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79661 Cc: n142857@HIDDEN, monnier@HIDDEN, 79661 <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: -3.3 (---) > Date: Mon, 20 Oct 2025 18:02:56 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: monnier@HIDDEN, n142857@HIDDEN, 79661 <at> debbugs.gnu.org > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> Date: Mon, 20 Oct 2025 15:40:59 +0000 > >> From: Pip Cet <pipcet@HIDDEN> > >> > >> This helps here, but I'm not sure it's the same bug: > >> > >> >From a9ad266ddbf02a5f309f40ff64f7407309ab7dd5 Mon Sep 17 00:00:00 2001 > >> From: Pip Cet <pipcet@HIDDEN> > >> Date: Mon, 20 Oct 2025 15:35:08 +0000 > >> Subject: [PATCH] Avoid quitting in keyboard_store_buffered_event (bug#79661) > >> > >> * src/keyboard.c (is_ignored_event): Use 'memq_no_quit', not 'Fmemq'. > >> --- > >> src/keyboard.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/src/keyboard.c b/src/keyboard.c > >> index e37f8ec7cdc..f525eff8cab 100644 > >> --- a/src/keyboard.c > >> +++ b/src/keyboard.c > >> @@ -13375,7 +13375,7 @@ is_ignored_event (union buffered_input_event *event) > >> default: ignore_event = Qnil; break; > >> } > >> > >> - return !NILP (Fmemq (ignore_event, Vwhile_no_input_ignore_events)); > >> + return !NILP (memq_no_quit (ignore_event, Vwhile_no_input_ignore_events)); > >> } > >> > >> static uint8_t > >> -- > >> 2.51.0 > >> > >> Fairly obvious explanation: Fmemq quits, we really shouldn't quit in the > >> middle of handling terminal input. > > > > Where is the call to Fmemq that quits in this case? When I put a > > #0 process_quit_flag () at eval.c:1882 > #1 0x00005555558370fc in probably_quit () at eval.c:1900 > #2 0x0000555555840ab6 in maybe_quit () at lisp.h:4184 > #3 0x0000555555846b1d in Fmemq (elt=XIL(0), list=XIL(0x7fffe2002d43)) at fns.c:1916 > #4 0x000055555578666a in is_ignored_event (event=0x7fffffff9f20) at keyboard.c:13378 > > > breakpoint inside 'quit', I don't see Fmemq in the backtrace. > > while-no-input "quits" don't go through "quit", they're handled by > "process_quit_flag". Look at the backtrace I posted: it tells a very different story. Not sure why, maybe we are looking at two separate issues. But I cannot see Fmemq anywhere when I repeat the recipe in a TTY session on GNU/Linux. > However, all of this depends on the timing somehow, it seems. Yes. As I wrote, the behavior is not completely deterministic. In 10% of cases, I can get the two characters inserted and no quit.
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 18:03:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 14:03:09 2025 Received: from localhost ([127.0.0.1]:47244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vAuDt-00050n-Dx for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 14:03:09 -0400 Received: from mail-10629.protonmail.ch ([79.135.106.29]:38389) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vAuDr-0004zr-9Z for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 14:03:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1760983379; x=1761242579; bh=tzq2KqYtWmauxecYWggHAwyrIjUcfcXgB5FZtR2sMAE=; 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; b=GOzxOP8mPLJXv99cy9Gn/AL6Imd/+2MUpgPNGt/JhOBAnrhNS83dEWj/7AwsTfyb0 dIH5v4WzX9O4uHAZrzGzI+VxzPZXSDUyULsbUWHvB/koXgjMRIsHzMn0T0n1VXdWb4 vEw2qfZVwjuXXAjdUvyl800raTBo4Ta3f3e8Bybkd5zPHLE3fClGCt2/SY7EoWikh9 SZEFv3Dtwtjkx5KKGYmWs6ZdgpEa/2+6mbh6C7GgcFhs9TsBsRhVmcmd+L7CgkpQBu 6+LUR29GZYdCk1v583zUs82Q9crw3SHHPB3JVmCkKSQ6qqpQddewC4ekIvlrHVYQe3 JzE3KyaATNOYg== Date: Mon, 20 Oct 2025 18:02:56 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY Message-ID: <87bjm1wizi.fsf@HIDDEN> In-Reply-To: <867bwpy1gu.fsf@HIDDEN> References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN> <87ms5lwpk2.fsf@HIDDEN> <867bwpy1gu.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 566437a9a400120fb7b13c390f650c1bfdf3d5ae 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: 79661 Cc: n142857@HIDDEN, monnier@HIDDEN, 79661 <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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Mon, 20 Oct 2025 15:40:59 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> >> This helps here, but I'm not sure it's the same bug: >> >> >From a9ad266ddbf02a5f309f40ff64f7407309ab7dd5 Mon Sep 17 00:00:00 2001 >> From: Pip Cet <pipcet@HIDDEN> >> Date: Mon, 20 Oct 2025 15:35:08 +0000 >> Subject: [PATCH] Avoid quitting in keyboard_store_buffered_event (bug#79= 661) >> >> * src/keyboard.c (is_ignored_event): Use 'memq_no_quit', not 'Fmemq'. >> --- >> src/keyboard.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/keyboard.c b/src/keyboard.c >> index e37f8ec7cdc..f525eff8cab 100644 >> --- a/src/keyboard.c >> +++ b/src/keyboard.c >> @@ -13375,7 +13375,7 @@ is_ignored_event (union buffered_input_event *ev= ent) >> default: ignore_event =3D Qnil; break; >> } >> >> - return !NILP (Fmemq (ignore_event, Vwhile_no_input_ignore_events)); >> + return !NILP (memq_no_quit (ignore_event, Vwhile_no_input_ignore_even= ts)); >> } >> >> static uint8_t >> -- >> 2.51.0 >> >> Fairly obvious explanation: Fmemq quits, we really shouldn't quit in the >> middle of handling terminal input. > > Where is the call to Fmemq that quits in this case? When I put a #0 process_quit_flag () at eval.c:1882 #1 0x00005555558370fc in probably_quit () at eval.c:1900 #2 0x0000555555840ab6 in maybe_quit () at lisp.h:4184 #3 0x0000555555846b1d in Fmemq (elt=3DXIL(0), list=3DXIL(0x7fffe2002d43)) = at fns.c:1916 #4 0x000055555578666a in is_ignored_event (event=3D0x7fffffff9f20) at keyb= oard.c:13378 > breakpoint inside 'quit', I don't see Fmemq in the backtrace. while-no-input "quits" don't go through "quit", they're handled by "process_quit_flag". There certainly are more bugs here, though: read_decoded_event_from_main_queue gets confused by the missed character, and this assertion fails: =09=09 eassert (coding->carryover_bytes =3D=3D 0); keyboard.c:2474: Emacs fatal error: assertion failed: coding->carryover_byt= es =3D=3D 0 However, all of this depends on the timing somehow, it seems. Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 16:36:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 12:36:46 2025
Received: from localhost ([127.0.0.1]:46835 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vAssI-0005Xe-6k
for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 12:36:46 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:47034)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vAssD-0005WK-Vl
for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 12:36:43 -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 1vAss8-0003FV-24; Mon, 20 Oct 2025 12:36:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=9sL9A/M7LUAISihR0NLhA06nhGa2cq2l1WF+DhPtPpE=; b=gkmrdeqtM+KQ
LTHi0NFlHTxDhWxGQ8qyGi4oerVe4fduW6EBWLwd/U3swTV/biWd4wP1SuRgT0qiFYg1zEL80+mYh
YUOcNh5Aye90ijJ9iqlfu6B1Jo1ghiXfuk2QdEQ3j+PQHbKt8X/s5/APKO6IprzkzhFf0si4ITFyW
uV9VYV8QysWAX0gZjdH+x/LoSDhTpVJEH2wfYXpv70B5PW8KI4yjNOpeJzHVt++LVBjEpc6vbUDMh
3W2NeSkffzCUu3m/qB8/S9jCdgw2hUDPwZ4K3lP9ML+y97D3zfgxP4m8IfvKZk9Zy30ykkMCPdUQm
qF8cPxnJ2Ncee+L3K/RwsQ==;
Date: Mon, 20 Oct 2025 19:36:33 +0300
Message-Id: <867bwpy1gu.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87ms5lwpk2.fsf@HIDDEN> (message from Pip Cet on Mon, 20
Oct 2025 15:40:59 +0000)
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
<87ms5lwpk2.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79661
Cc: n142857@HIDDEN, monnier@HIDDEN, 79661 <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: -3.3 (---)
> Date: Mon, 20 Oct 2025 15:40:59 +0000
> From: Pip Cet <pipcet@HIDDEN>
>
> This helps here, but I'm not sure it's the same bug:
>
> >From a9ad266ddbf02a5f309f40ff64f7407309ab7dd5 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet@HIDDEN>
> Date: Mon, 20 Oct 2025 15:35:08 +0000
> Subject: [PATCH] Avoid quitting in keyboard_store_buffered_event (bug#79661)
>
> * src/keyboard.c (is_ignored_event): Use 'memq_no_quit', not 'Fmemq'.
> ---
> src/keyboard.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/keyboard.c b/src/keyboard.c
> index e37f8ec7cdc..f525eff8cab 100644
> --- a/src/keyboard.c
> +++ b/src/keyboard.c
> @@ -13375,7 +13375,7 @@ is_ignored_event (union buffered_input_event *event)
> default: ignore_event = Qnil; break;
> }
>
> - return !NILP (Fmemq (ignore_event, Vwhile_no_input_ignore_events));
> + return !NILP (memq_no_quit (ignore_event, Vwhile_no_input_ignore_events));
> }
>
> static uint8_t
> --
> 2.51.0
>
> Fairly obvious explanation: Fmemq quits, we really shouldn't quit in the
> middle of handling terminal input.
Where is the call to Fmemq that quits in this case? When I put a
breakpoint inside 'quit', I don't see Fmemq in the backtrace.
It sounds like with-local-quit (called from while-no-input) somehow
doesn't work in the TTY case, allowing the 'quit' call after BODY is
correctly interrupted. What I see in the backtrace is this:
Thread 1 "emacs" hit Breakpoint 4, quit () at eval.c:1907
1907 return signal_or_quit (Qquit, Qnil, true);
(gdb) bt
#0 quit () at eval.c:1907
#1 process_quit_flag () at eval.c:1861
#2 probably_quit () at eval.c:1869
#3 0x0000560a1a7b652c in maybe_quit ()
at /home/eliz/git/emacs/trunk/src/lisp.h:3919
#4 exec_byte_code
(fun=XIL(0), args_template=455880, nargs=2, args=0x7fe185a461c8)
at bytecode.c:763
#5 0x0000560a1a762f15 in Ffuncall (nargs=1, args=0x7ffc5d32b140)
at eval.c:3174
#6 0x0000560a1a7645e9 in call0 (fn=XIL(0x560a5583acf5))
at /home/eliz/git/emacs/trunk/src/lisp.h:3490
#7 Fhandler_bind_1 (nargs=<optimized out>, args=0x7fe185a46108) at eval.c:1556
#8 0x0000560a1a7b672a in exec_byte_code
(fun=XIL(0), args_template=455880, nargs=3, args=0x7fe185a46108)
at /home/eliz/git/emacs/trunk/src/lisp.h:2234
#9 0x0000560a1a762f15 in Ffuncall
(nargs=nargs@entry=2, args=args@entry=0x7ffc5d32b2c8) at eval.c:3174
#10 0x0000560a1a75df73 in Ffuncall_interactively (nargs=2, args=0x7ffc5d32b2c8)
at callint.c:250
which AFAIU is part of condition-case processing in
with-local-quit(??). IOW, we quite _after_ while-no-input correctly
throws out of the body. the problem is that throwing clears the value
of throw-on-input, whereas quit-flag still has the value 'input' that
came from while-no-input. So quit-flag is non-nil, but not eq to
throw-on-input, and we quit.
Maybe this will ring some bells in Stefan's ears.
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 15:41:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 11:41:18 2025
Received: from localhost ([127.0.0.1]:46683 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vAs0b-0001Ak-UJ
for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 11:41:18 -0400
Received: from mail-4322.protonmail.ch ([185.70.43.22]:47201)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vAs0X-0001A8-9i
for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 11:41:14 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1760974866; x=1761234066;
bh=VvZyeHCHpvohiEvLHHDFrnk2iWskUjT4Y9OCOjaehcE=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=lwHLkkI0y/fOdAVeamb/UMYZprDFcXjP1F9NKKBxVyoui62am2Tw+9NtEwC9Vael/
5sejAUTLyVLEhiw7nyT2cFM8NoH/EKv/4WLoDgBhcxiccrOnIpErGcNGsxuFhEhiMi
FhuG2D4Ql1+NpKXe5aMOnbkEGtQjUiDp20HW3eF8d9dcc3IlVuxhGNJRCyNRkFR1FH
zMxHXddwEeyhSkKARTzgWYYcSrLB5bahaFnMRjjT9O1K+DHA7vQYbVQDeqkMniPbMz
G9UX0uKggTdjnl853BUf22P0DCOfKn0qq3b7ClOoOm3gh6nLakfHTj7SgsmVE87J+G
yBBAGCwXEMZmg==
Date: Mon, 20 Oct 2025 15:40:59 +0000
To: Eli Zaretskii <eliz@HIDDEN>, Stefan Monnier <monnier@HIDDEN>,
Daniel Clemente <n142857@HIDDEN>, 79661 <at> debbugs.gnu.org
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79661: 31.0.50;
while-no-input outputs raw codes if interrupted by a key with a
3-byte UTF-8 sequence in a TTY
Message-ID: <87ms5lwpk2.fsf@HIDDEN>
In-Reply-To: <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: dfc3927d55d5c99f5c883d72ab7997aa5bdbb99f
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: 79661
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 via \"Bug reports for GNU Emacs, the Swiss army knife of te=
xt editors\"" <bug-gnu-emacs@HIDDEN> writes:
>>> (while-no-input
>>> (message "Starting")
>>> (sleep-for 4)
>>> (message "Finishing")
>>> )
>>>
>>> The behaviour I see now is:
>>>
>>> 1. If I let it run, it shows both messages
>>> 2. If I interrupt it by pressing "a", I still have to wait the 4
>>> seconds, and in the end I see "a". Apparently 1 letter isn't enough to
>>> stop it. A bit unexpected, but that's not the point of this bug
>
> I don't see this here with Debian's Emacs-30.1 running in an `xterm` with
> `emacs -Q -nw`), nor any of the other weird behaviors you describe.
> I do see most of it with my own build (with lots of extra debugging) of
> Emacs' master.
>
> Hmm...
>
>> Stefan, any ideas?
>
> Not really, no. My intuition tells me that the "inconsistencies"
> come from the exact same underlying problem as the UTF-8 garbage: we end
> up throwing away some bytes from the input. My crystal ball suggests it
> may be related to the `discard-input` we usually do in `C-g`.
>
> In the above code, we're not supposed to discard any input, so I'd start
> by tracking down where/why we discard this input.
This helps here, but I'm not sure it's the same bug:
From a9ad266ddbf02a5f309f40ff64f7407309ab7dd5 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Mon, 20 Oct 2025 15:35:08 +0000
Subject: [PATCH] Avoid quitting in keyboard_store_buffered_event (bug#79661=
)
* src/keyboard.c (is_ignored_event): Use 'memq_no_quit', not 'Fmemq'.
---
src/keyboard.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/keyboard.c b/src/keyboard.c
index e37f8ec7cdc..f525eff8cab 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -13375,7 +13375,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 uint8_t
--=20
2.51.0
Fairly obvious explanation: Fmemq quits, we really shouldn't quit in the
middle of handling terminal input.
However, this assumes Vwhile_no_input_ignore_events isn't circular.
Pip
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 15:39:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 11:39:52 2025 Received: from localhost ([127.0.0.1]:46675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vArzD-0000yy-DJ for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 11:39:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:36552) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vArz3-0000xy-Lm for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 11:39:47 -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 1vAryx-0004At-Fx; Mon, 20 Oct 2025 11:39:35 -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=ANVLZNf9r2Dq1wHDpDqcPDY7f+LQTRezGrMHTsWkGMg=; b=eQYEHKU+r/cw 6AKD/KMzcQNh3uZ/ZCisztFu6zO093Zmdy2zmTGn42tlqU6c9lfg0HVfYpHDzb8ebo0noi0Zk7SUp fLCZf36C1wVTg/jU7nOzDqObE75u766IFPIfpwRgzl9/qa57NkUu+CaAfH45L+E3HhVnhhqys6TsP rzBSAwxNIhqv57XfNYRsivdAIQF1MFBeUHnedgSje30tmzeySer8guiJeuX6Ksb5TAEUI+bec+RzI /SDhpY62gD8Lh8kCBlTD9LFOKRHQIm3VN/O/obmiHv4uy/H+NGS+SyYZDAiDTvnfIW+eJSAty2LCP ozMfmjZQ7tRvkwQnq+KOvA==; Date: Mon, 20 Oct 2025 18:39:31 +0300 Message-Id: <86a51ly43w.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Mon, 20 Oct 2025 11:11:12 -0400) Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86qzuxye53.fsf@HIDDEN> <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79661 Cc: n142857@HIDDEN, 79661 <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: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: Daniel Clemente <n142857@HIDDEN>, 79661 <at> debbugs.gnu.org > Date: Mon, 20 Oct 2025 11:11:12 -0400 > > > Stefan, any ideas? > > Not really, no. My intuition tells me that the "inconsistencies" > come from the exact same underlying problem as the UTF-8 garbage: we end > up throwing away some bytes from the input. My crystal ball suggests it > may be related to the `discard-input` we usually do in `C-g`. > > In the above code, we're not supposed to discard any input, so I'd start > by tracking down where/why we discard this input. That's actually clear: we discard input because we quit (I see the telltale visual-bell ringing). The question is why we quit in this case. (The original recipe is actually not very interesting: who would call sleep-for inside while-no-input? And how is the presence of sleep-for contributing to the outcome?)
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 15:11:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 11:11:29 2025
Received: from localhost ([127.0.0.1]:46620 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vArXk-0007nR-OV
for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 11:11:29 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:3583)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <monnier@HIDDEN>)
id 1vArXh-0007md-GE
for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 11:11:26 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 84675441652;
Mon, 20 Oct 2025 11:11:19 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1760973078;
bh=iSOIC86lLwBtlCdEDOeN68d7Z7BVzpxV9uPT5/+qTUE=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=SCRYv7Qqj2jRX5jpw19WGLKBhgTQGHcWHAijwy6sgTUkhrUmBWim+x9oQWP9ZvX7f
xgYIx8jhWhq45MruPxdU2uaGT0HEUXFU0BEnGJm2tce1PKggZiRLrxJduv3wkMMcVu
rZJEiDIQgGzEgMxnp4als4uz8Cizl+c+tNGYR3134UftoSKb1fNFmx6JPfOY/N2pvK
f+dcVISltHPYtyy+HIAhjVd1NlyTyyoDzYQEaL6e3ElfrZCXDzW9Uh0+Mt3NHtlYzS
6c3e1hrOdd2fBirLlMbHyKtwOpSS7VqhoG1/CvqhxvTxJag4fo6QDet60LVkgw2ktH
8Sh2enS9saJYg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6040B4415F6;
Mon, 20 Oct 2025 11:11:18 -0400 (EDT)
Received: from asado (unknown [181.28.45.30])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 20C97120401;
Mon, 20 Oct 2025 11:11:16 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if
interrupted by a key with a 3-byte UTF-8 sequence in a TTY
In-Reply-To: <86qzuxye53.fsf@HIDDEN>
Message-ID: <jwvsefdoc5p.fsf-monnier+emacs@HIDDEN>
References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN>
<86qzuxye53.fsf@HIDDEN>
Date: Mon, 20 Oct 2025 11:11:12 -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.029 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: 79661
Cc: Daniel Clemente <n142857@HIDDEN>, 79661 <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: -3.3 (---)
>> (while-no-input
>> (message "Starting")
>> (sleep-for 4)
>> (message "Finishing")
>> )
>>
>> The behaviour I see now is:
>>
>> 1. If I let it run, it shows both messages
>> 2. If I interrupt it by pressing "a", I still have to wait the 4
>> seconds, and in the end I see "a". Apparently 1 letter isn't enough to
>> stop it. A bit unexpected, but that's not the point of this bug
I don't see this here with Debian's Emacs-30.1 running in an `xterm` with
`emacs -Q -nw`), nor any of the other weird behaviors you describe.
I do see most of it with my own build (with lots of extra debugging) of
Emacs' master.
Hmm...
> Stefan, any ideas?
Not really, no. My intuition tells me that the "inconsistencies"
come from the exact same underlying problem as the UTF-8 garbage: we end
up throwing away some bytes from the input. My crystal ball suggests it
may be related to the `discard-input` we usually do in `C-g`.
In the above code, we're not supposed to discard any input, so I'd start
by tracking down where/why we discard this input.
Stefan
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 14:31:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 10:31:59 2025 Received: from localhost ([127.0.0.1]:46410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vAqvW-0004G9-S2 for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 10:31:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33376) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vAqvS-0004Fp-R8 for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 10:31:55 -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 1vAqvL-0001wW-U2; Mon, 20 Oct 2025 10:31:49 -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=1rxopDh7twMJVc94PGrlc3Bfn1DGUY/DG3QNO/qXSpY=; b=ZWXV7PHDJIxsCv7FibGM x6gJKkmcDY8loUgHsbxrmsNfC/hhDRpQaKHWLrFj3qwpya4QkskOjTx+bodxKMICv/XBEIaWVJ6sx TBgqSGPDBe9IQNJEb4/za7R3LlwtkwYeCPUvpcwllDmuXYS6P9qVfxcAm2Rn9dpMdswtZ4wY1yffv 2RaNObdfWKzJ8BkkztLfb250/rmA4yG7SvDeyKXQsx8E/Yn79kfiNY3l5Zz8gIyHw01cx4v8J9Ehx fxP3hMy1QXM+awR0JT/9YZNw068c6FQQ0PujYAfcYH1T5pNoJsfXDYQkwrqcL45wJVLSI4NMnXSze olDZTpNXYM8RCw==; Date: Mon, 20 Oct 2025 17:31:31 +0300 Message-Id: <86cy6hy798.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: n142857@HIDDEN, monnier@HIDDEN In-Reply-To: <86qzuxye53.fsf@HIDDEN> (message from Eli Zaretskii on Mon, 20 Oct 2025 15:02:48 +0300) Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> <86qzuxye53.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: 79661 Cc: 79661 <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: -3.3 (---) > Cc: 79661 <at> debbugs.gnu.org > Date: Mon, 20 Oct 2025 15:02:48 +0300 > From: Eli Zaretskii <eliz@HIDDEN> > > > From: Daniel Clemente <n142857@HIDDEN> > > Date: Mon, 20 Oct 2025 09:30:46 +0000 > > > > I use emacs in a TTY (urxvt, but I also tried xterm and kitty, with > > the same results). > > > > emacs -nw -Q > > > > (while-no-input > > (message "Starting") > > (sleep-for 4) > > (message "Finishing") > > ) > > > > > > The behaviour I see now is: > > > > 1. If I let it run, it shows both messages > > 2. If I interrupt it by pressing "a", I still have to wait the 4 > > seconds, and in the end I see "a". Apparently 1 letter isn't enough to > > stop it. A bit unexpected, but that's not the point of this bug > > 3. If I interrupt it by pressing "ab", it immediately stops, and shows > > nothing (it eats the "ab"). Ok… I don't mind > > 4. If I interrupt it by pressing "abc", it immediately stops, and shows "c". Ok… > > 5. Here comes the bug: if I interrupt it by pressing "→a" (I get "→" > > by pressing AltGr+t in my custom keyboard layout), then it stops and > > adds unexpected raw codes to the buffer: \342\206a > > 6. If I interrupt it by pressing "ñ", it immediately stops and shows "ñ". Ok > > > > Note that "ñ" is 2 UTF-8 bytes (maybe therefore it behaves like the "ab" case). > > But "→" is 3 UTF-8 bytes (e2 86 92, in decimal it's 226 134 146). > > The garbage codes happen when the pressed key requires more than 2 UTF-8 bytes. > > > > If I just press "→" several times, then the garbage codes appear after > > each keypress (\342\206\206\222\206\222\206\222\206\222 and so on), > > until I press an ASCII key. > > > > The practical consequence is: when using e.g. helm (which uses > > while-no-input), sometimes there may be garbage codes when typing > > fast. See description and video at: > > https://github.com/emacs-helm/helm/issues/2730 > > (Ignore the comments there about GC, this isn't related to GC). > > > > I don't mind the inconsistencies in while-no-input, but this bug is > > mainly about making it not output garbage codes like \222\206, > > \342\210\203, etc. If anything, it can output the symbols pressed (→ ← > > … ∃ „ 明 ∴ etc.). Or output nothing. > > > > You may have to add one of those symbols to your layout, with setxkbmap. > > Stefan, any ideas? Btw, if you repeat the recipe many times, you will see that the behavior is not entirely deterministic: it evidently depends on how long do you wait after evaluating the code before you type the input.
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at 79661) by debbugs.gnu.org; 20 Oct 2025 12:03:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 08:03:09 2025 Received: from localhost ([127.0.0.1]:44422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vAobU-0005zA-Hv for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 08:03:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45122) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vAobR-0005yO-JU for 79661 <at> debbugs.gnu.org; Mon, 20 Oct 2025 08:03:06 -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 1vAobI-0004En-4D; Mon, 20 Oct 2025 08:02:58 -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=7QUz+rWJ6rJSaj3BJIX27CITdKIndICguGFpDNpwh6s=; b=MJDqNsYqbHXqFslYThwv vxFi+8PDCialfSGGVhxNpCK80/AZdCjordVcmiP3oYevDLDKs97tPtCleTBCWmKttAadFXRec+caS 1qyPcG/XVEhvBwaGeoejo0JnBhOiJb9EJz9HWWMKQWy3SEXsk5/+bbY1ks+7Ya4xlruO+tqEMCEsx u2vv0vxpXpN+uEa092Lsd2TnKA+HO7HKwPym3P5ukkplJ2nMa8Ke3abbfMK2R1/KW5pXCjn783QbG 6ioJ1AinPIWytcn++XYflPWNffAEUpbxFKA7UruYC1nr+SbHozCui5JgQDAtm/DWOZwVKnJ3S4tu5 nJFSICZ0ckIW9w==; Date: Mon, 20 Oct 2025 15:02:48 +0300 Message-Id: <86qzuxye53.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Clemente <n142857@HIDDEN>, Stefan Monnier <monnier@HIDDEN> In-Reply-To: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> (message from Daniel Clemente on Mon, 20 Oct 2025 09:30:46 +0000) Subject: Re: bug#79661: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY References: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@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: 79661 Cc: 79661 <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: -3.3 (---) > From: Daniel Clemente <n142857@HIDDEN> > Date: Mon, 20 Oct 2025 09:30:46 +0000 > > I use emacs in a TTY (urxvt, but I also tried xterm and kitty, with > the same results). > > emacs -nw -Q > > (while-no-input > (message "Starting") > (sleep-for 4) > (message "Finishing") > ) > > > The behaviour I see now is: > > 1. If I let it run, it shows both messages > 2. If I interrupt it by pressing "a", I still have to wait the 4 > seconds, and in the end I see "a". Apparently 1 letter isn't enough to > stop it. A bit unexpected, but that's not the point of this bug > 3. If I interrupt it by pressing "ab", it immediately stops, and shows > nothing (it eats the "ab"). Ok… I don't mind > 4. If I interrupt it by pressing "abc", it immediately stops, and shows "c". Ok… > 5. Here comes the bug: if I interrupt it by pressing "→a" (I get "→" > by pressing AltGr+t in my custom keyboard layout), then it stops and > adds unexpected raw codes to the buffer: \342\206a > 6. If I interrupt it by pressing "ñ", it immediately stops and shows "ñ". Ok > > Note that "ñ" is 2 UTF-8 bytes (maybe therefore it behaves like the "ab" case). > But "→" is 3 UTF-8 bytes (e2 86 92, in decimal it's 226 134 146). > The garbage codes happen when the pressed key requires more than 2 UTF-8 bytes. > > If I just press "→" several times, then the garbage codes appear after > each keypress (\342\206\206\222\206\222\206\222\206\222 and so on), > until I press an ASCII key. > > The practical consequence is: when using e.g. helm (which uses > while-no-input), sometimes there may be garbage codes when typing > fast. See description and video at: > https://github.com/emacs-helm/helm/issues/2730 > (Ignore the comments there about GC, this isn't related to GC). > > I don't mind the inconsistencies in while-no-input, but this bug is > mainly about making it not output garbage codes like \222\206, > \342\210\203, etc. If anything, it can output the symbols pressed (→ ← > … ∃ „ 明 ∴ etc.). Or output nothing. > > You may have to add one of those symbols to your layout, with setxkbmap. Stefan, any ideas?
bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 20 Oct 2025 09:31:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 20 05:31:31 2025 Received: from localhost ([127.0.0.1]:43774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vAmEk-0001MC-Rk for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 05:31:31 -0400 Received: from lists.gnu.org ([2001:470:142::17]:34368) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <n142857@HIDDEN>) id 1vAmEi-0001LS-8W for submit <at> debbugs.gnu.org; Mon, 20 Oct 2025 05:31:29 -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 <n142857@HIDDEN>) id 1vAmEa-0000vK-N7 for bug-gnu-emacs@HIDDEN; Mon, 20 Oct 2025 05:31:20 -0400 Received: from mail-vk1-xa33.google.com ([2607:f8b0:4864:20::a33]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <n142857@HIDDEN>) id 1vAmEX-00083g-Rm for bug-gnu-emacs@HIDDEN; Mon, 20 Oct 2025 05:31:19 -0400 Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-556694876eeso1606088e0c.3 for <bug-gnu-emacs@HIDDEN>; Mon, 20 Oct 2025 02:31:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760952673; x=1761557473; darn=gnu.org; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RV6FKl2MduonKEFQZn5E+gX35U9vjz1ctEArdd8Mnsc=; b=dhMG7YZB4PhsWS71qcGud0iXcjycGDVuAE7eRVlBfewPYZS5rNEhyzAfT5NBfhmUwr nQxrGe40TJa1f9rvj9Ya49AaVNJ6xZBvISiodNepY3Nvh6ayFcvldWkLioPKSmsidmsm 1qJOABDiTWo+T78c8/eBdcX07aaPlBSP6qnce4za9PYUoNcyEBJ0zbb/lu9tOBjaqrWv IoiOM3ZzTccNdCEADxYWhNIwI0cd04bOoJ648UCC1/kbdwx3+gtGtL3mNT5u+sEgfEkC Dhj0cQbfZgAZTD2PbLE2GuHNXxK6qQEva3wov6a7v7VqGWp66QaiVsasjPsrZ1LTCk74 +7gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760952673; x=1761557473; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RV6FKl2MduonKEFQZn5E+gX35U9vjz1ctEArdd8Mnsc=; b=TjiKCdKfi9LCKMakswi9RcX+wm26CWMLFN8QnilSjs9X4N29blVou5aLYis3EnRO+F t3f+45iLXNfIVYjWEWwdnO47q6vYInqcdP2Q1XwmTYhJwgq/rHnyzg4R5kadEzSpaBHN 1ixv2+urF6JCDkjij/PowGq1qdCoSGqM9gtbqkKf61EFYnyGGEn5tuBPQr0TGmT/AlVy IXBySaMJzlxKOIyEAVbc2jAoJWwuxEesoWnHwjmZBMu7ynK0L1MnuEjaNDH8VjFymksO 2TnzHVvcJBZzwpYBUR5itIY8k+VBrIFJdVIyQ+WkvVlaSb9KYFA3axKtxnlU4lknUqwS BYRg== X-Gm-Message-State: AOJu0Yw/QHmf4yaAZEQSUk7Wd4XC/f825HMs4VCrONquEoMakz5g+pb9 3YfoBEO44xk831A3s40XurfiNmIV5VE3RpvShQRP1C9hEfik3DdBsDV6rh8f+R74re6pRo81wJQ zICoQ8x5erUpCQ6X4DK4MwB0QxTX7bINT1eng X-Gm-Gg: ASbGncs8Nmae7vnuNqf+amwfEf7QnPBs1usWRqsMcyCWP07AZbZeTs3z3b/4Qk/ZPCZ LPydmSmIKGY9wPT7X16LsWnN6ZbM42n5awzXhC5mQLAVXc6JEghTGBgb2KXkliYHBve8TtN2oPR evyCTeZLdHs28DfEpvkcxsRrACyMotrnJrO8ayWA7jnXW57H7WDCkVVsZT1VU/uv4Gpuo8PnaKS GyxxjxJVTtaywa/lGAXXiAU9lQ5C6n0nditHiCKYftSkV8HCRmZLObjiEMqugT7Akeer/yaPfzk pyN4eHzFguIIUB6COk/sVEaJKNzNvkuCfvxg10MoBimBswBV9gmW3DCeSP0NvMmX8XVMg2y6wgK eKeGvb7IfvpXUgBiT/xTPTok+57Cc+G+ykS1qjeE6KY1L0TrLVGFr8d/BcJSGo4qdXMPcn07RSQ syqK3ZCgMgJEDwNXQwqsKV3C0w62+JA3KDWJYwFILXuO++JakKxwEPl4svHb4gtq2qsZ8= X-Google-Smtp-Source: AGHT+IEccpHyTLMUMIVG+Fn3z/jLh6k2z+JmVKp2p1ensbStyMbQVwNX2hs0CCT5Z5FIJvQzy/ko/Ast9xylMAU+kLQ= X-Received: by 2002:a05:6122:2a14:b0:544:71fb:f49b with SMTP id 71dfb90a1353d-5564eeeb9bamr4145462e0c.10.1760952673319; Mon, 20 Oct 2025 02:31:13 -0700 (PDT) MIME-Version: 1.0 From: Daniel Clemente <n142857@HIDDEN> Date: Mon, 20 Oct 2025 09:30:46 +0000 X-Gm-Features: AS18NWAFIGetl2mzSlRuO9noO9K7tXujbGyxmkg88MOV1L6ZY4rzMMKZT-6hQEY Message-ID: <CAJKAhPBK_hL4bzo9S5y+uVSCiGZa5AbPdAfTeYfBm2EzdVKPfw@HIDDEN> Subject: 31.0.50; while-no-input outputs raw codes if interrupted by a key with a 3-byte UTF-8 sequence in a TTY To: bug-gnu-emacs@HIDDEN Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::a33; envelope-from=n142857@HIDDEN; helo=mail-vk1-xa33.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: I use emacs in a TTY (urxvt, but I also tried xterm and kitty, with the same results). emacs -nw -Q (while-no-input (message "Starting") (sleep-for 4) (message "Finishing") ) Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (n142857[at]gmail.com) 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (n142857[at]gmail.com) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org] 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.2 (/) I use emacs in a TTY (urxvt, but I also tried xterm and kitty, with the same results). emacs -nw -Q (while-no-input (message "Starting") (sleep-for 4) (message "Finishing") ) The behaviour I see now is: 1. If I let it run, it shows both messages 2. If I interrupt it by pressing "a", I still have to wait the 4 seconds, and in the end I see "a". Apparently 1 letter isn't enough to stop it. A bit unexpected, but that's not the point of this bug 3. If I interrupt it by pressing "ab", it immediately stops, and shows nothing (it eats the "ab"). Ok=E2=80=A6 I don't mind 4. If I interrupt it by pressing "abc", it immediately stops, and shows "c"= . Ok=E2=80=A6 5. Here comes the bug: if I interrupt it by pressing "=E2=86=92a" (I get "= =E2=86=92" by pressing AltGr+t in my custom keyboard layout), then it stops and adds unexpected raw codes to the buffer: \342\206a 6. If I interrupt it by pressing "=C3=B1", it immediately stops and shows "= =C3=B1". Ok Note that "=C3=B1" is 2 UTF-8 bytes (maybe therefore it behaves like the "a= b" case). But "=E2=86=92" is 3 UTF-8 bytes (e2 86 92, in decimal it's 226 134 146). The garbage codes happen when the pressed key requires more than 2 UTF-8 by= tes. If I just press "=E2=86=92" several times, then the garbage codes appear af= ter each keypress (\342\206\206\222\206\222\206\222\206\222 and so on), until I press an ASCII key. The practical consequence is: when using e.g. helm (which uses while-no-input), sometimes there may be garbage codes when typing fast. See description and video at: https://github.com/emacs-helm/helm/issues/2730 (Ignore the comments there about GC, this isn't related to GC). I don't mind the inconsistencies in while-no-input, but this bug is mainly about making it not output garbage codes like \222\206, \342\210\203, etc. If anything, it can output the symbols pressed (=E2=86= =92 =E2=86=90 =E2=80=A6 =E2=88=83 =E2=80=9E =E6=98=8E =E2=88=B4 etc.). Or output nothing= . You may have to add one of those symbols to your layout, with setxkbmap. In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu) of 2025-09-17 built on sonn Repository revision: 29d46a2e759a7781e4c0fc5d14b8415189d83656 Repository branch: master System Description: Devuan GNU/Linux 5 (daedalus) Configured using: 'configure --prefix=3D/opt/dc/emacs/ --without-dbus --without-lcms2 --without-libsystemd --without-dbus --without-sound --with-mailutils --with-native-compilation=3Dyes --without-modules --with-x-toolkit=3Dno --without-xim --without-imagemagick --without-xft --without-harfbuzz --without-libotf --without-xwidgets --without-xpm --with-tiff=3Dno --without-tiff --without-jpeg --without-gif --without-png --without-webp --without-rsvg --without-cairo --without-x 'CFLAGS=3D-g3 -O2'' Configured features: GMP GNUTLS LIBSELINUX LIBXML2 NATIVE_COMP NOTIFY INOTIFY PDUMPER SECCOMP SQLITE3 THREADS XIM ZLIB Important settings: value of $LANG: en_US.UTF-8 value of $XMODIFIERS: @im=3DSCIM locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t minibuffer-regexp-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug lisp-mnt message mailcap yank-media puny dired dnd dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils compile text-property-search comint subr-x ansi-osc ansi-color ring tool-bar comp-run comp-common regexp-opt rx term/rxvt term/xterm xterm byte-opt gv bytecomp byte-compile warnings icons cl-loaddefs cl-lib rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads inotify multi-tty make-network-process tty-child-frames native-compile emacs) Memory information: ((conses 16 75358 9749) (symbols 48 7126 1) (strings 32 18839 1373) (string-bytes 1 599653) (vectors 16 8450) (vector-slots 8 102721 6583) (floats 8 27 11521) (intervals 56 261 0) (buffers 984 12))
Daniel Clemente <n142857@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#79661; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.