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

From: Pip Cet <[email-masked]>
Date: Sun, 15 Jun 2025 18:06:32 +0000

"Stefan Monnier" <[email-masked]> writes:

>> We should steer developers away from read-char and towards higher level
>> features like read-key anyway, right?
>
> +1

I agree in principle, but right now it's unpredictable whether read-key
returns "7" for a C-g or signals a quit, at least when you use X and
your timing is a bit off.  The observed behavior is this:

If I suspend Emacs while it's in (read-key), type C-g in the suspended
window, and unsuspend it, I usually get a quit.  If I don't, I seem to
always get a 7.  (This is probably because the focus-in event and the
quit event arrive simultaneously, as far as read_char is concerned).

There are so many small buglets and unexplained oddities in this code
that I think an overhaul is needed.  We should probably open a new bug
for the general topic of how C-g relates to various kinds of quitting
(normal, urgent, emergency escape), and how it can be simplified (why do
we still have getcjmp? Is it for the MSDOS port exclusively?)

However, opening that bug would ideally involve a somewhat complete
description of the current, chaotic situation (read-key isn't the only
function that makes it depend on timing, or timers, how quits are
handled).  And that takes some time.  I mean things like "sometimes
unread-command-events get looked up in special-event-map, but usually
they don't".

But I suggest we fix the original easily-fixed sit-for bug in one of the
various minimally invasive ways we've found, and start out with a fresh
bug.  The current discussion is impossible for anyone else to read.

Pip