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

Previous Next

Full log

View this message in rfc822 format

From: Daniel Colascione <dancol <at> dancol.org>
To: Eli Zaretskii <eliz <at> gnu.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: Wed, 11 Jun 2025 14:44:57 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Daniel Colascione <dancol <at> dancol.org>
>> Cc: pipcet <at> protonmail.com,  monnier <at> iro.umontreal.ca,  78737 <at> debbugs.gnu.org
>> Date: Wed, 11 Jun 2025 09:35:48 -0700
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> I went through all the uses of read-char, read-char-exclusively, and
>> >> read-event in the tree and didn't find anything that'll break if we make
>> >> these functions return C-g as an event.
>> >
>> > How did you look for potential problems?  E.g., the C-g flow is
>> > impossible to see in the code, you need to try it; doing that in all
>> > the possible places where we use this stuff and with all the different
>> > timings is practically impossible, I think.
>> 
>> 
>> I tried everything (e.g. kbd-macro-query) where the effect wasn't
>> obvious from the code.  And I'm not sure what "timings" you're talking
>> about here: read-char, etc. will now _deterministically_ return \?C-g on
>> quit, so there's no timing involved.
>
> I mean with the current code: C-g pressed at different times could
> produce different effects.

Given that these "different times" have been nondeterministic and that
there's no legitimate reason a program would rely on them, I don't see
our having introduced any timing issues, and none have shown up in
my tests.

>> For the broader change to quit, well, I've been using the thing and have
>> seen no problems.  isearch works fine.  Macros work fine.
>> minibuffer-quit in a macro works just as it did before too.
>
> The problem with this stuff, in our experience, is that different
> people use different setups and workflows, and problems tend to depend
> on that.  Which is why it takes time until they get reported.

In theory, Hyrum's law can bite you any time, but I'm just not seeing
behavior depend on a timing bug.  The read-event contract could in
theory break someone, but I still haven't seen evidence of it
actually happening.

>> Input methods work fine --- at least greek, russian-typewriter, and
>> Chinese 4-corners.  Any others you think might be particularly hairy?
>
> Some of the East Asian, perhaps.  Also, using input methods as part of
> recording keyboard macros caused trouble at some point.

There's one East Asian input method in the list already.

>> With the exception of read-char, read-char-exclusively, and read-event,
>> the Lisp API contract hasn't changed: wherever we would previously run
>> the command bound to C-g most of the time, we now run all the time.
>> That's not going to break anything: we're merely taking something that
>> was 1) supposed to happen, and 2) usually did happen, and make it happen
>> in all the cases users expect it to happen.  Keep in mind that you've
>> always been able to bind commands to C-g: it's just that previously, C-g
>> would occasionally fail to invoke these commands.  Now it does.
>
> What about the effect of quit-flag?

Nothing about the meaning of quit-flag has changed.

>> Lisp quits work normally.  Better, actually: the NS port now even
>> reliably quits where it's supposed to quit.  The debugger works fine.
>> edebug works too.  debug-on-quit works.  Recursive edits ---
>> no difference.
>
> What about C-g on Unix TTYs?  Including when there are additional Lisp
> threads?

Unix TTYs work fine.

Threads work as well as they ever have: both in master and on my branch,
this puts Emacs into an unresponsive and unquittable state:

    (make-thread (lambda () (while t)) "spinner")

At least it's not a regression.

Basic accept-process-output with a reasonable timeout on a thread works
fine and doesn't interfere with interactive quitting and other
UI interactions.

>
>> I'll add the kill switch you wanted.  I don't think it's necessary, but
>> it's not going to do any harm.  Other than this kill switch and making
>> sure SIGUSR2 quits out of read-event, it seems fine to me.
>
> We should ask more people to try the branch, especially on other
> platforms.

Previous Next

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