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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 78737 <at> debbugs.gnu.org, pipcet <at> protonmail.com, monnier <at> iro.umontreal.ca
Subject: bug#78737: sit-for behavior changes when byte-compiled
Date: Thu, 12 Jun 2025 21:34:31 +0300

> Date: Thu, 12 Jun 2025 11:04:06 -0700
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: pipcet <at> protonmail.com, monnier <at> iro.umontreal.ca, 78737 <at> debbugs.gnu.org
> 
> 
> 
> On June 12, 2025 9:56:26 AM PDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> Date: Thu, 12 Jun 2025 09:52:22 -0700
> >> From: Daniel Colascione <dancol <at> dancol.org>
> >> CC: monnier <at> iro.umontreal.ca, 78737 <at> debbugs.gnu.org
> >> 
> >> 
> >> 
> >> On June 12, 2025 9:32:26 AM PDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> >> Date: Thu, 12 Jun 2025 13:58:51 +0000
> >> >> From: Pip Cet <pipcet <at> protonmail.com>
> >> >> Cc: Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca, 78737 <at> debbugs.gnu.org
> >> >> 
> >> >> 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?

Previous Next

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