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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78737 <at> debbugs.gnu.org, pipcet <at> protonmail.com, dancol <at> dancol.org
Subject: bug#78737: sit-for behavior changes when byte-compiled
Date: Sat, 14 Jun 2025 10:05:46 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Daniel Colascione <dancol <at> dancol.org>,  pipcet <at> protonmail.com,
>   78737 <at> debbugs.gnu.org
> Date: Fri, 13 Jun 2025 14:07:20 -0400
> 
> > My current understanding is that what you propose will cause some
> > (most) programs to be interruptible with a single C-g, while some (in
> > particular those which call read-event) will need two or more C-g to
> > be interrupted.  Is that correct?
> 
> I think so, tho only for *some* of those which call `read-event`.

If read-event always returns 7, then the "*some*" part is incorrect,
as long as C-g was pressed while we are in read-event.

> > If this is correct, then we need to decide whether this inconsistency
> > (one C-g vs several) is tolerable.
> 
> That inconsistency already exists in various places, such as if you use
> `read-key`.

Yes, but it's a known inconsistency, with which we lived for many
years.  We are now introducing a new inconsistency.

This is a practical matter, not an academic one.  Some people and some
applications will be surprised, and some applications will not work as
they did before.  Telling them that we always had a similar
inconsistency will not help.

> I think what we need to decide is if the resulting overall
> behavior is better (e.g. easier to describe and less error prone), and
> if so, whether it's worth the incompatibility.

Yes, we do need to make that decision.  However:

  . we need first to agree on the design and the implementation of new
    code, and
  . we then need to describe the resulting behavior in clear enough
    terms for others to understand and reason about it

Then we need to describe these changes on emacs-devel and see if the
changes in behavior are acceptable by the community.

> Of course, we could also make the change more backward-compatible by
> renaming `read-event` to some new name and (re)defining `read-event` on
> top of that new function.

That's yet another possibility, yes.  But given the original
motivation (the problems in transient.el), I doubt if this is a viable
solution.

Previous Next

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