Subject: Re: bug#78737: sit-for behavior changes when byte-compiled

From: Pip Cet <[email-masked]>
Date: Fri, 13 Jun 2025 16:04:41 +0000

"Stefan Monnier" <[email-masked]> writes:

>> -    ;; 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?).

You're right, there are differences (such as the hourglass displaying in
one case but not the other, it seems).  No obvious way to call
wait_reading_process_output with precisely the right parameters.  Let's
drop this one for now.

Inhibit-quit and quitting before rather than after removing an event
from the queue should still both fix the original problem, if that's
what we decide to do for now.

Pip