GNU bug report logs - #78737
sit-for behavior changes when byte-compiled

Previous Next

Full log

Message #185 received at 78737 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 78737 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, pipcet <at> protonmail.com
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Date: Fri, 13 Jun 2025 10:28:23 -0400

>> 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).

Maybe `kill -USR2` would work better?  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.

> (It's dancol/quit-improvements2 not dancol/quit-improvements because I
> can't force-push even to a non-mainline branch.  Shouldn't we allow
> off-mainline force pushes?)

Someone mentioned the `scratch/` convention.  Note that the repository
will still refuse `git push --force`: you need to first delete the old
branch with `git push :scratch/foo` and then push the new branch on top.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.