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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Colascione <dancol <at> dancol.org>
Cc: 78737 <at> debbugs.gnu.org, pipcet <at> protonmail.com, monnier <at> iro.umontreal.ca
Subject: Re: bug#78737: sit-for behavior changes when byte-compiled
Date: Sat, 14 Jun 2025 13:35:40 +0300

> Date: Sat, 14 Jun 2025 06:24:40 -0400
> From: Daniel Colascione <dancol <at> dancol.org>
> CC: monnier <at> iro.umontreal.ca, 78737 <at> debbugs.gnu.org
> 
> >Last, but not least, this is not directly related to the main part of
> >this discussion, which is about being able to interrupt Lisp programs
> >by a single C-g.
> 
> 
> Why is it so important that a *single* C-g interrupt a Lisp program?

Only because it was possible (with some exceptions) until today.
Thus, any change in this will be rightfully considered to be an
incompatible change in behavior

> If a Lisp program is reading input, and C-g is input, treating at least the first C-g as input is expected, and like I said, it's just not possible to interrupt with a single C-g a program expecting to read input that is also a single C-g. If you try to achieve this goal you either break the input capability or you break the single C-g quit, and you're not addressing this contradiction head on.

We moved past these arguments, so why go back now?  I didn't say we
_must_ preserve previous behavior of a single C-g, I just said what is
this discussion about.  Let's argue where we disagree, not where we
don't.

Previous Next

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