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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 12 Jun 2025 21:34:31 +0300

> Date: Thu, 12 Jun 2025 11:04:06 -0700
> From: Daniel Colascione <[email-masked]>
> CC: [email-masked], [email-masked], [email-masked]
> 
> 
> 
> On June 12, 2025 9:56:26 AM PDT, Eli Zaretskii <[email-masked]> wrote:
> >> Date: Thu, 12 Jun 2025 09:52:22 -0700
> >> From: Daniel Colascione <[email-masked]>
> >> CC: [email-masked], [email-masked]
> >> 
> >> 
> >> 
> >> On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii <[email-masked]> wrote:
> >> >> Date: Thu, 12 Jun 2025 13:58:51 +0000
> >> >> From: Pip Cet <[email-masked]>
> >> >> Cc: Eli Zaretskii <[email-masked]>, [email-masked], [email-masked]
> >> >> 
> >> >> I'd say breaking (read-event) called in a loop is bad enough, because
> >> >> how else are you supposed to start developing code which uses it?
> >> >
> >> >Maybe this regression should be fixed, then.
> >> 
> >> It's not a regression. It's a bug fix. Not every behavior change is a problem. Who starts coding something by calling it in a loop? That's like learning to drive by crashing into a wall.
> >
> >Did it never happen to you that you wrote a loop and forgot the part
> >that advances the counter or some other thing that will prevent an
> >infloop?  Stuff happens when developing code.
> 
> And the mechanism I described just now addresses the problem of recovering from programmer error.

Sorry, I must have missed it (assuming that was in your previous
message).  Could you please point me to that description, or repeat
it?

Specifically, what I'm interested in is how come

 (while t
   (read-event))

cannot be interrupted by C-g, but you seem to be saying that

 (while t
   (let (evt (read-event))
     (do-something-with evt)))

_can_ be interrupted?  Let's say when I type C-g, the loop is stuck
inside read-event: could you then describe how this latter loop could
be interrupted in that case?