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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 12 Jun 2025 19:32:26 +0300

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

> Since we've progressed to testing the branch, with the implication being
> that we'll merge it soon, it may be too late to make alternative
> suggestions.

We will merge only after we agree that (a) it does TRT, and (b) that
it was tested sufficiently well and all the problems it might cause
have been dealt with.

So it isn't too late to argue that the branch does something
incorrectly or sub-optimally.

> I think this discussion is concerned too much with what existing code
> will break if we change quit not to quit, not enough with how much more
> difficult it will be to develop code if we do, and not at all, so far,
> with what the advantages of handling quit in Lisp (if Lisp decides to
> handle it at all) are.
> 
> C-g isn't an input event in the same way that kicking someone in the
> shin is not a dance move.  I want it to kick Emacs in the shin, and
> break out of bad Lisp code, in *more* situations than it does now.

Please describe the situations where you'd like it to throw to top
level and it doesn't now.  Also, can this behavior be optional, like
debug-on-error and friends are?  Not everyone debugs Lisp code all the
time, so we definitely can have an "easy-break-out" feature that is by
default off.

> Maybe a compromise would be to continue the arms race and downgrade C-g
> to normal input, C-g C-g C-g to a quit, and require even more C-g's for
> a force-quit?

That's also possible, though less desirable: counting C-g presses when
you are desperate is not easy and we cannot rely on users to do that
reliably.

> > Along the same lines, we could get rid of getcjmp too.  I'm not afraid
> > of rationalizing the contract of read-event or tweaking any other part
> > of keyboard.c, but that thing and quit_throw_to_read_char are extremely
> > confusing and do scare me a bit --- all the more reason, in my mind, to
> > get rid of them, like Gerd wanted to do years ago.  When is the right
> > time to do that?  It's not like an Emacs 31 release is imminent.
> 
> I think that's a different discussion, to be honest.

I agree, and I think so does Daniel.