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

From: Eli Zaretskii <[email-masked]>
Date: Wed, 11 Jun 2025 22:21:00 +0300

> From: Daniel Colascione <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Wed, 11 Jun 2025 09:35:48 -0700
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> >> I went through all the uses of read-char, read-char-exclusively, and
> >> read-event in the tree and didn't find anything that'll break if we make
> >> these functions return C-g as an event.
> >
> > How did you look for potential problems?  E.g., the C-g flow is
> > impossible to see in the code, you need to try it; doing that in all
> > the possible places where we use this stuff and with all the different
> > timings is practically impossible, I think.
> 
> 
> I tried everything (e.g. kbd-macro-query) where the effect wasn't
> obvious from the code.  And I'm not sure what "timings" you're talking
> about here: read-char, etc. will now _deterministically_ return \?C-g on
> quit, so there's no timing involved.

I mean with the current code: C-g pressed at different times could
produce different effects.

> For the broader change to quit, well, I've been using the thing and have
> seen no problems.  isearch works fine.  Macros work fine.
> minibuffer-quit in a macro works just as it did before too.

The problem with this stuff, in our experience, is that different
people use different setups and workflows, and problems tend to depend
on that.  Which is why it takes time until they get reported.

> Input methods work fine --- at least greek, russian-typewriter, and
> Chinese 4-corners.  Any others you think might be particularly hairy?

Some of the East Asian, perhaps.  Also, using input methods as part of
recording keyboard macros caused trouble at some point.

> With the exception of read-char, read-char-exclusively, and read-event,
> the Lisp API contract hasn't changed: wherever we would previously run
> the command bound to C-g most of the time, we now run all the time.
> That's not going to break anything: we're merely taking something that
> was 1) supposed to happen, and 2) usually did happen, and make it happen
> in all the cases users expect it to happen.  Keep in mind that you've
> always been able to bind commands to C-g: it's just that previously, C-g
> would occasionally fail to invoke these commands.  Now it does.

What about the effect of quit-flag?

> Lisp quits work normally.  Better, actually: the NS port now even
> reliably quits where it's supposed to quit.  The debugger works fine.
> edebug works too.  debug-on-quit works.  Recursive edits ---
> no difference.

What about C-g on Unix TTYs?  Including when there are additional Lisp
threads?

> I'll add the kill switch you wanted.  I don't think it's necessary, but
> it's not going to do any harm.  Other than this kill switch and making
> sure SIGUSR2 quits out of read-event, it seems fine to me.

We should ask more people to try the branch, especially on other
platforms.