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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 14 Jun 2025 10:12:55 +0300

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Fri, 13 Jun 2025 14:14:44 -0400
> 
> >> >  (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.

That's not what I see on the branch.  read-event returns the character
7, a scalar.  Or am I missing something?

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

So you are saying that, to be interruptible by a single C-g, a Lisp
program that calls read-event will need to have code that quits under
certain circumstances when read-event returns 7, is that right?
Doesn't that mean we will now require every program that calls
read-event to have such Lisp code, where it previously didn't?
Pushing quitting to the application level is not something that will
be appreciated by Lisp programmers, I think.