GNU bug report logs -
#78737
sit-for behavior changes when byte-compiled
Previous Next
Full log
Message #188 received at 78737 <at> debbugs.gnu.org (full text, mbox):
On June 13, 2025 7:28:23 AM PDT, Stefan Monnier <monnier <at> iro.umontreal.ca> 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.
This bug report was last modified 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.