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

From: Stefan Monnier <[email-masked]>
Date: Fri, 13 Jun 2025 11:04:27 -0400

> This code is used everywhere, and we have no one on board who knows it
> (and its many quirks and platform-dependent subtleties) well enough.
> It isn't an accident that we prefer not to make changes in it: each
> time we made even small changes in this code we ended up with
> regressions.  We don't have any decent test suite for the this part of
> Emacs.  We don't even have an exhaustive list of
> features/commands/operations to test in order to make sure some change
> doesn't break them.  Notable corners that get frequently broken by
> changes in this area: keyboard macros, Leim input methods, and
> non-keyboard input events.

Yes, that's what I see as the main benefit of Daniel's suggestion: it
makes the behavior a bit simpler to describe (assuming there isn't some
nasty implementation detail which leaves some corner case open), so it
would help make that code a bit more manageable.

Ideally it should come with some documented design rationale of how
`inhibit-quit` is expected to be used and behave in general (i.e. in
what kind of circumstances it should be bound and where/when it
shouldn't, ...).

I have no delusion that it can be done without introducing some
regressions.

        Stefan