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

Previous Next

Full log

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

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

On June 13, 2025 2:14:44 PM EDT, Stefan Monnier <monnier <at> iro.umontreal.ca> wrote:
>>> >  (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.
>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

Yes. It's not reliable today. An example I gave earlier: on master, putting C-g into unread-command-events makes the next read-event  return 7, not signal quit.

>`inhibit-quit` and sometimes timing), so if we want to encourage use of
>that feature we should try and make it more reliable.

We should steer developers away from read-char and towards higher level features like read-key anyway, right?

Previous Next

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