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

Previous Next

Full log

View this message in rfc822 format

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

[Message part 1 (text/plain, inline)]

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.

Lynn

[Message part 2 (text/html, inline)]

Previous Next

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