Subject: Re: bug#78737: sit-for behavior changes when byte-compiled

From: Daniel Colascione <[email-masked]>
Date: Tue, 10 Jun 2025 02:32:50 -0700

Pip Cet <[email-masked]> writes:

> "Daniel Colascione" <[email-masked]> 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.