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

From: Daniel Colascione <[email-masked]>
Date: Sat, 14 Jun 2025 06:54:58 -0400

On June 14, 2025 3:12:55 AM EDT, Eli Zaretskii <[email-masked]> wrote:
>> From: Stefan Monnier <[email-masked]>
>> Cc: [email-masked],  [email-masked],  [email-masked]
>> Date: Fri, 13 Jun 2025 14:14:44 -0400
>> 
>> >> >  (while t
>> >> >    (let (evt (read-event))
>> >> >      (do-something-with evt)))
>> >> >
>> >> > _can_ be interrupted?
>> >> 
>> >> Usually the `(do-something-with evt)` part will offer some way to end
>> >> the loop.
>> >
>> > How?  If read-event returns the character 7, then the information
>> > about the fact that C-g was typed is lost by the time we get to the
>> > do-something-with part, no?
>> 
>> AFAIK that information is in `evt` and hence not lost.
>
>That's not what I see on the branch.  read-event returns the character
>7, a scalar.  Or am I missing something?

That's the encoding of C-g. What information is lost?

>> Usually `do-something-with` will look at `evt` and do various things
>> depending on the key that was pressed and usually one of those options
>> lets you end what you were doing.
>> 
>> Some code may assume they don't need to explicitly abort when `evt` is
>> 7 because they rely on the current behavior of `read-event`, but AFAIK
>> that behavior is not completely reliable (e.g. it depends on
>> `inhibit-quit` and sometimes timing), so if we want to encourage use of
>> that feature we should try and make it more reliable.
>
>So you are saying that, to be interruptible by a single C-g, a Lisp
>program that calls read-event will need to have code that quits under
>certain circumstances when read-event returns 7, is that right?
>Doesn't that mean we will now require every program that calls
>read-event to have such Lisp code, where it previously didn't?

I've seen that in practice are interruptable in this manner already. It looks like use of higher level functions like read-key or transient maps is already more common in higher level code and that this code already reacts properly to receiving C-g as input.

I do see a bit of variety in what programs actually do when they get C-g though. Some signal quit. Some call keyboard-quit, which is harmless because it eventually signals quit, but is less clear and does unnecessary work before signaling quit.

It'd be nice to guide high-level and low-level input readers alike to quit by signaling quit rather than trying to call keyboard-quit and such themselves.

>Pushing quitting to the application level is not something that will
>be appreciated by Lisp programmers, I think.

We've been pushing quitting to applications for decades when these applications use the higher level input reading functions. Check out how we do it in, e.g. calc. I haven't seen any objections.