GNU bug report logs -
#78737
sit-for behavior changes when byte-compiled
Previous Next
Full log
View this message in rfc822 format
> 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
a program that calls read-event becomes interruptible by a single C-g,
after the changes on the branch? The above loop is not interruptible,
but Daniel says that his proposal allows interrupting Lisp programs,
just not silly programs such as the one above. So if we start from
the above silly program, and add to it some meaningful processing of
the event read by read-event, at what point does such a program become
interruptible by a single C-g?
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? If it is, then what will a single C-g
produce? will it _never_ cause a quit?
If my understanding above is correct, then this is a significant
change in behavior, and it is not yet implemented on the branch. I
would suggest to discuss this change in behavior on emacs-devel before
we decide to make the change (perhaps even before it is implemented,
to prevent waste of development efforts in case the proposal is voted
down).
Whether we need an "emergency quit" (whatever that means) is a
related, but separate question. Currently, what we have is the
"emergency exit", which doesn't quit, but kills the session (with or
without a core dump), and IME it doesn't work reliably in GUI
sessions. Again, this is IMO a separate feature and a separate
discussion. The discussion about what a single C-g does and how to
interrupt Lisp programs using C-g is much more important and therefore
much more complicated.
This bug report was last modified 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.