GNU bug report logs -
#78737
sit-for behavior changes when byte-compiled
Previous Next
Full log
Message #236 received at 78737 <at> debbugs.gnu.org (full text, mbox):
"Stefan Monnier" <monnier <at> iro.umontreal.ca> 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
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.