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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 78737 <at> debbugs.gnu.org, pipcet <at> protonmail.com, monnier <at> iro.umontreal.ca
Subject: bug#78737: sit-for behavior changes when byte-compiled
Date: Tue, 10 Jun 2025 18:56:22 +0300

> Date: Tue, 10 Jun 2025 08:06:46 -0700
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: pipcet <at> protonmail.com, 78737 <at> debbugs.gnu.org
> 
> IOW, C-g in the command loop can mean cmderror or does it mean C-g. How do you know? Roll the dice. The user cannot predict whether redisplay is going to run at the exact moment he whacks a key. This particular aspect of the system has been ambiguous for a long time (ever since redisplay got the ability to run Lisp?) and ultimately comes from C-g being overloaded in the first place.

First, redisplay is not part of the command loop, at least not
conceptually: when redisplay runs, we don't respond to user input.

And second, where we call Lisp from redisplay and cannot tolerate C-g
(or don't think it would be useful), we bind inhibit-quit already.

So I don't think I follow what you are saying here.

> That's *not* the same as just binding inhibit-quit around reading events like transient tries to do. The problem with binding inhibit-quit is that, well, you can't quit. Quitting restartable things that tend to get wedged like redisplay is useful.

It might be useful in principle, but if you allow that, you'll have an
infinite redisplay loop on your hands.  Why? because quitting has the
side effect of showing "Quit" in the echo area, which re-enters
redisplay right away, and will then wedge the same way as the one from
which you wanted to escape.  And second, because it isn't restartable.

So aborting redisplay is tricky at best.  We have an optional feature,
by default off, which does that, see max-redisplay-ticks.  If you
follow how this is implemented when we decide to abort, you will see
it isn't simple.  And my personal experience from using this is that
sometimes you are left with a partially-redrawn screen that you (as
the user) don't always know how to fix.

> Instead, the event reading functions should internally translate quits.to quit_char returns even if a quit happened internally. And they definitely shouldn't return with quit-flag set.

How can this support breaking out of a runaway synchronous subprocess?
Or any of the similar situations which today we can interrupt with a
C-g? are we going to give up on them?

Previous Next

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