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

From: Daniel Colascione <[email-masked]>
Date: Fri, 13 Jun 2025 07:36:57 -0700

On June 13, 2025 7:28:23 AM PDT, Stefan Monnier <[email-masked]> wrote:
>>> I like your way of thinking.  I'm not completely sure it will solve
>>> world hunger, and it may come with regressions, but it's worth a try.
>>> Given the pervasive impact, it might be best to have a global config var
>>> to enable/disable it (with some scary internal name) until we're
>>> confident that it's an improvement.
>>
>> Check out the branch dancol/quit-improvements2 with a fix for this
>> problem and multiple others I found along the way.  There, we make
>> read_char report quits as quit_char, protect timer callbacks against
>> quits properly, inhibit quits in redisplay by default, attempt to quit
>> more often reading process output, and fix the original
>> throw-on-input bug.
>
>Regarding "inhibit quits in redisplay by default": I've several times
>got my way out of a jit-lock hang (not necessarily an info-loop,
>e.g. a nasty regexp explosion) by leaning on `C-g` (the actual behavior
>sucks, because the quit is caught by the redisplay which then jumps
>right back into the same jit-lock code, toh apparently there's a bit of
>progress made along the way, hence the need to lean on `C-g` for a while).

Agreed. See my spec on the other thread. In terms of that post, we'd break out of redisplay when #quits >= M: this condition means we'd ignore the inhibit-quit when deciding whether to Fsignal in response to a quit. It's also worth putting an explicit maybe_quit at the end of redisplay_internal if we don't have one already.

>Maybe `kill -USR2` would work better? 

Thanks for reminding me to mention SIGUSR2. We'll treat it like #quits >= M.

> Still, while I agree that we
>should generally inhibit quits during redisplay, inhibiting all quits is
>a problem, so I often wish we had two notions of quits: the "normal
>quit" and the "emergency quit", where the emergency quit puts more
>emphasis on making sure we stop what we're doing than on preserving
>a "clean" state (e.g. I don't mind some redisplay glitches after an
>emergency quit from jit-lock).  We'd still want to stay away from core
>dumps, of course

That's what I'm proposing.