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

Previous Next

Full log

Message #260 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: Fri, 13 Jun 2025 20:47:43 +0300

> Date: Fri, 13 Jun 2025 09:14:20 -0700
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: pipcet <at> protonmail.com, 78737 <at> debbugs.gnu.org
> 
> On June 13, 2025 9:03:21 AM PDT, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> >> Cc: Daniel Colascione <dancol <at> dancol.org>,  78737 <at> debbugs.gnu.org,  Eli
> >>  Zaretskii <eliz <at> gnu.org>
> >> Date: Fri, 13 Jun 2025 10:51:37 -0400
> >> 
> >> > Making
> >> >
> >> >     (while t (read-event))
> >> >
> >> > infloop without being able to quit is a bad idea.  We shouldn't do it.
> >> 
> >> I don't find this terribly problematic, If you think of what that loop
> >> means it *is* a "please shoot me in the foot" kind of thing.
> >> 
> >> I agree that not being able to escape is a problem, but it's not the
> >> only way to get into such trouble.  IOW I think it just gets us back to
> >> the fact that we need an "emergency quit" for bugs (which `kill -USR2`
> >> can sometimes provide, tho it's not a quit per-se).
> >
> >What I asked, and still didn't get an answer to, is at what point does
> 
> I believe I answered your question at length in <https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-06/msg00678.html> and specifically addressed the question above. I believe I'd addressed the subject several times before as well.
> 
> Could you please take a look at the proposal before declaring these questions unanswered?

I did.

My current understanding is that what you propose will cause some
(most) programs to be interruptible with a single C-g, while some (in
particular those which call read-event) will need two or more C-g to
be interrupted.  Is that correct?

If this is correct, then we need to decide whether this inconsistency
(one C-g vs several) is tolerable.

> >Later responses by Daniel seem to indicate that the answer is "never".
> >It seems like his proposal is to change the behavior of C-g such that
> >to interrupt a Lisp program the user will need two or more C-g presses
> >(with the number customizable) during some predefine time interval.
> >Is that understanding correct?
> 
> No, that is not correct, and I've said so many times. I'm not sure what I could say to increase clarity.

Is the modified description above correct?  If not, what is incorrect
in it?

> Outside contrived corner cases, the only difference users will notice is that quitting works more reliably.

Thanks, but that doesn't answer my question, which is specifically
about the effect of C-g on Lisp programs, whether they call read-event
or don't call it.

Previous Next

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