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

Previous Next

Package: emacs;

Reported by: Daniel Colascione <dancol <at> dancol.org>

Date: Mon, 9 Jun 2025 20:50:02 UTC

Severity: normal

Full log


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

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: Re: bug#78737: sit-for behavior changes when byte-compiled
Date: Thu, 12 Jun 2025 06:29:13 -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 14:44:57 -0700
>> 
>> >> 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.
>
> Time will tell.  IME, these assumptions tend to break, at least
> sometimes.
>
> >> 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.
>
> I hear you.  I'm just saying that if experience has taught us anything
> in this area, it's that we should encourage as many people as possible
> on as many different platforms as possible to try the new code and
> report back.
>
>> >> 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.
>
> Yes, but they work differently, so a few more won't hurt.
>
>> >> 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.
>
> You mean, you didn't intend for it to change, right?  But the changes
> on the branch definitely access and set it in several places, so it
> _could_ change, albeit inadvertently.  Thus, I think it would be good
> to test that as well.  The test suite uses inhibit-quit in 2 places,
> so maybe run those tests, both interactively and noninteractively?
> Also, searching the tree for "quit-flag" comes up with a few dozen
> matches, so maybe look into those places and see if they still work as
> expected?

I've already tried everything that AFAICT might reasonably have broken
as a result of the change, including its use of quit-flag, and didn't
see anything wrong. I've been using the thing too. I'd expect that if
I'd broken something fundamental, bugs would have shown up by now. But
sure, let's test the branch and see whether anyone else can find
something wrong.




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.