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

Previous Next

Full log

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

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

> Cc: 78737 <at> debbugs.gnu.org
> From: Daniel Colascione <dancol <at> dancol.org>
> Date: Tue, 10 Jun 2025 02:32:50 -0700
> 
> Pip Cet <pipcet <at> protonmail.com> writes:
> 
> > "Daniel Colascione" <dancol <at> dancol.org> writes:
> >
> >> Consider (while-no-input (sit-for 100)).
> >>
> >> Run it and press any key, say, f to terminate the wait. You'll see "f"
> >> inserted wherever point was.
> >>
> >> Now eval-defun on sit-for from subr.el and try (while-no-input (sit-for
> >> 100)) again. The "f" disappears.
> >>
> >> Why? Because Fread_event returns with Vquit_flag set; the byte-compiled
> >> sit-for is able to push the event onto Vunread_command_events before
> >> Lisp does something quit-able, but the interpreted sit-for doesn't get
> >> so far and loses Fread_event's return value.
> >>
> >> Fread_event should probably look for Vquit_flag and !Vinhibit_quit and
> >> in this case stick the event on Vunread_command_events itself and
> >> return nil.
> >
> > 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?

Previous Next

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