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

Previous Next

Full log

Message #122 received at 78737 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#78737: sit-for behavior changes when byte-compiled
Date: Thu, 12 Jun 2025 19:56:26 +0300

> 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.

> You have to think about these things, not just reflexively conclude that it's bad because it's different.

Daniel, you are not the only one who thinks about this.  The fact that
people disagree doesn't necessarily mean they didn't think.  Let's try
to leave such "arguments" out of the discussion.

Previous Next

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