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

From: Daniel Colascione <[email-masked]>
Date: Fri, 13 Jun 2025 14:43:54 -0400

On June 13, 2025 2:14:44 PM EDT, Stefan Monnier <[email-masked]> wrote:
>>> >  (while t
>>> >    (let (evt (read-event))
>>> >      (do-something-with evt)))
>>> >
>>> > _can_ be interrupted?
>>> 
>>> Usually the `(do-something-with evt)` part will offer some way to end
>>> the loop.
>>
>> How?  If read-event returns the character 7, then the information
>> about the fact that C-g was typed is lost by the time we get to the
>> do-something-with part, no?
>
>AFAIK that information is in `evt` and hence not lost.
>Usually `do-something-with` will look at `evt` and do various things
>depending on the key that was pressed and usually one of those options
>lets you end what you were doing.
>
>Some code may assume they don't need to explicitly abort when `evt` is
>7 because they rely on the current behavior of `read-event`, but AFAIK
>that behavior is not completely reliable (e.g. it depends on

Yes. It's not reliable today. An example I gave earlier: on master, putting C-g into unread-command-events makes the next read-event  return 7, not signal quit.

>`inhibit-quit` and sometimes timing), so if we want to encourage use of
>that feature we should try and make it more reliable.

We should steer developers away from read-char and towards higher level features like read-key anyway, right?