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

Previous Next

Full log

View this message in rfc822 format

From: Daniel Colascione <dancol <at> dancol.org>
To: Lynn Winebarger <owinebar <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 78737 <at> debbugs.gnu.org, Pip Cet <pipcet <at> protonmail.com>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#78737: sit-for behavior changes when byte-compiled
Date: Fri, 13 Jun 2025 06:42:58 -0700

On June 13, 2025 5:23:34 AM PDT, Lynn Winebarger <owinebar <at> gmail.com> wrote:
>On Fri, Jun 13, 2025, 2:26 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Daniel Colascione <dancol <at> dancol.org>
>> > Cc: Eli Zaretskii <eliz <at> gnu.org>,  monnier <at> iro.umontreal.ca,
>> >   78737 <at> debbugs.gnu.org
>> > Date: Thu, 12 Jun 2025 11:48:50 -0700
>> >
>> > Pip Cet <pipcet <at> protonmail.com> writes:
>> >
>> > > I'd like read-event, when called while inhibit-quit is t, to report
>> > > quits by setting quit-flag in addition to returning quit_char: it'll
>> > > simplify the C code, and it would make
>> > >
>> > > (while t
>> > >   (let ((inhibit-quit t))
>> > >     (read-event)))
>> >
>> > I strongly disagree.  read-event should read an event.
>> > Setting quit-flag by side effect when it happens to read one key and not
>> > others makes the interface less regular and understandable.
>>
>> We should start by agreeing that the capability of interrupting a
>> running Lisp program is a real need.  Are we in agreement about that?
>> If not, let's first hear the arguments why not.
>>
>> If we _are_ in agreement about that, we should discuss how this should
>> be possible if read-event (and perhaps others?) return C-g instead of
>> raising quit-flag.  The alternatives mentioned until now are:
>>
>>  . restore the old behavior, whereby C-g interrupts read-event
>>  . have a variable that, if set, will restore the old behavior in
>>    read-event and other affected primitives, to be interruptible by a
>>    single C-g
>>  . make two C-g presses "in quick succession" set quit-flag, IOW
>>    "C-g C-g" will have the same effect as C-g previously
>>
>> Are there other alternatives?
>>
>
>What about keeping a (possibly buffer-local?) lisp variable holding a list
>of keystrokes mapped to thunks that are treated as generating lisp machine
>"interrupts"?  The key strokes would be processed by C machinery and never
>seen directly by lisp code and not be considered "events".
>Then C-g could be bound to a thunk signalling quit, and the effect of
>"inhibit-quit" achieved by removing C-g from the list in a given dynamic
>scope.  Then user code could make other key-strokes "special" without
>resorting to read-event.  For example, this read-event call in term.el:
>(message "Hit space to flush")
>      (let ((ch (read-event)))
> (if (eq ch ?\s)
>     (set-window-configuration conf)
>   (push ch unread-command-events)))
>
>Could be replaced by something like
>(with-interrupts ((?\s (signal term-flush)))
>  (condition-case nil
>    (while t (sit-for 100))
>     (term-flush (set-window-configuration conf))))
>
>Then some of these use-case concerns could be mooted altogether.

We already have something like that. :-) read-event already runs the events it reads through special-event-map, right? We don't even need to create a separate thunk list concept: we could just bind C-g in special event map and do what we want, right?

The only special thing about C-g is how we treat it when Lisp is running. When it's instead reading an event, it can and be a boring event processed the same way every other event is.

Previous Next

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