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

Previous Next

Full log

View this message in rfc822 format

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

>> > Until we fix sit-for by adding a mechanism to peek at rather than read
>> > and dequeue input events, would it be sufficient just to bind
>> > inhibit-quit while reading and unreading the event?  It appears to work,
>> > at least.
>> 
>> And the other callers of read-event?  Might as well just fix it at the source.
>
> Stefan, any comments or suggestions?

As Pip says, it would be nice to have way to peek rather than
read+unread (the reason we don't AFAIK is that we don't just want to
peek at the next event but at "some" next event while ignoring
presumably irrelevant others, like mouse movements, so it's a bit less
trivial than it sounds).

Our handling of `inhibit-quit` is not very systematic, right now (and
we've recently seen some of the impact, with the patch for
`transient.el`).  E.g. it's bound while running timers but not while
running jit-lock code.  It's never really clear why it's done at one
place and not at others.

Maybe doing it whenever we're waiting for user input (i.e. in
`read_char`), like Daniel suggests, is not a bad idea and might be
closer to The Right Way to use `inhibit-quit`.

But then we need to make sure that when `read_char` returns a quit
event, the caller eventually acts on this event.


        Stefan

Previous Next

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