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

Previous Next

Full log

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

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

> -    ;; FIXME: we should not read-event here at all, because it's much too
> -    ;; difficult to reliably "undo" a read-event by pushing it onto
> -    ;; unread-command-events.
> -    ;; For bug#14782, we need read-event to do the keyboard-coding-system
> -    ;; decoding (hence non-nil as second arg under POSIX ttys).
> -    ;; For bug#15614, we need read-event not to inherit-input-method.
> -    ;; So we temporarily suspend input-method-function.
> -    (let ((read (let ((input-method-function nil))
> -                  (read-event nil t seconds))))
> -      (or (null read)
> -	  (progn
> -            ;; https://lists.gnu.org/r/emacs-devel/2006-10/msg00394.html
> -            ;; We want `read' appear in the next command's this-command-event
> -            ;; but not in the current one.
> -            ;; By pushing (cons t read), we indicate that `read' has not
> -            ;; yet been recorded in this-command-keys, so it will be recorded
> -            ;; next time it's read.
> -            ;; And indeed the `seconds' argument to read-event correctly
> -            ;; prevented recording this event in the current command's
> -            ;; this-command-keys.
> -	    (push (cons t read) unread-command-events)
> -	    nil))))))
> +    (not (if throw-on-input
> +             (sleep-for seconds)
> +           (while-no-input (sleep-for seconds)))))))

I'm not sure this will wake up on the same events (i.e. whether its
notion of what is "not a real input event" is the same).  `sit-for` has
seen several iterations because of "corner cases", so I wouldn't be
surprised to bump into regressions, but I agree that it would be nice to
"align" the notion of "relevant" events used by `sit-for` with that used
by `while-no-input`.
[ IIRC part of the differences are the events handled by
  `special-event-map`.  ]

Note also that I'm not sure `sleep-for` will actually do what we want
here (does it run process filters and timers?  And update the display
accordingly?).


        Stefan

Previous Next

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