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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 14 Jun 2025 11:14:04 +0300

> From: Gerd Möllmann <[email-masked]>
> Cc: Daniel Colascione <[email-masked]>,  [email-masked],  Eli
>  Zaretskii <[email-masked]>,  Pip Cet <[email-masked]>,  Lynn
>  Winebarger <[email-masked]>
> Date: Sat, 14 Jun 2025 05:43:41 +0200
> 
> Stefan Monnier <[email-masked]> writes:
> 
> >>> We already have something like that. :-) read-event already runs the
> >>> events it reads through special-event-map, right?
> >> Entirely unrelated, I just came across this because I searched for
> >> read-event. Let me just mention that read-event does not respect
> >> input-decode-map. This is a problem on ttys, see bug#75886.
> >
> > Currently the only "decoding" we have to turn the TTY input bytes into
> > events is limited to the keyboard-coding-system thingy.  🙁
> >
> > Maybe I should have implemented `input-decode-map` directly inside
> > `read-event`, but I think it goes contrary to the design.
> >
> > It's usually better to change the users to use a higher-level function
> > instead, such as `read-key`.
> >
> > Admittedly, if you want to recognize a quit event encoded as an escape
> > sequence, that's not going to help you because we need/want those events
> > to be decoded at as-low a level as we can. 🙁
> 
> I'd deprecate read-event TBH.

If we want to do this, we should start by removing it from our own
sources.  Currently, we use it in around 80 places.