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

Previous Next

Full log

Message #11 received at 78737 <at> debbugs.gnu.org (full text, mbox):

From: Daniel Colascione <dancol <at> dancol.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: 78737 <at> debbugs.gnu.org
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Date: Tue, 10 Jun 2025 02:32:50 -0700

Pip Cet <pipcet <at> protonmail.com> writes:

> "Daniel Colascione" <dancol <at> dancol.org> writes:
>
>> Consider (while-no-input (sit-for 100)).
>>
>> Run it and press any key, say, f to terminate the wait. You'll see "f"
>> inserted wherever point was.
>>
>> Now eval-defun on sit-for from subr.el and try (while-no-input (sit-for
>> 100)) again. The "f" disappears.
>>
>> Why? Because Fread_event returns with Vquit_flag set; the byte-compiled
>> sit-for is able to push the event onto Vunread_command_events before
>> Lisp does something quit-able, but the interpreted sit-for doesn't get
>> so far and loses Fread_event's return value.
>>
>> Fread_event should probably look for Vquit_flag and !Vinhibit_quit and
>> in this case stick the event on Vunread_command_events itself and
>> return nil.
>
> Until we fix sit-for by adding a mechanism to peek at rather than read
> and dequeue input events, would it be sufficient just to bind
> inhibit-quit while reading and unreading the event?  It appears to work,
> at least.

And the other callers of read-event?  Might as well just fix it at the source.

Previous Next

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