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>
> Cc: pipcet <at> protonmail.com, monnier <at> iro.umontreal.ca, 78737 <at> debbugs.gnu.org
> Date: Wed, 11 Jun 2025 07:57:52 -0700
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Anyway, I think arguing about this aspect is not useful. My problem
> > is not theoretical, it is practical: how much will break due to these
> > changes, and how long will it take us to become aware of the breakage
> > and attempt fixing it?
>
> I went through all the uses of read-char, read-char-exclusively, and
> read-event in the tree and didn't find anything that'll break if we make
> these functions return C-g as an event.
How did you look for potential problems? E.g., the C-g flow is
impossible to see in the code, you need to try it; doing that in all
the possible places where we use this stuff and with all the different
timings is practically impossible, I think.
The number of possible combinations of affected APIs with
while-no-input and other stuff sensitive to this is also quite close
to infinite. And then there are keyboard macros, input methods (which
not all of them work the same with unread-command-events etc.) and
more.
> > And I know what will break. As I told, we don't have a good set of
> > tests for it. I only know that every time we changed something in
> > read_char and its ilk in recent years, we ended up with regressions.
>
> All the more reason to simplify its contract.
If simplifying the contract removes support for valid use cases, we
break something, and need to somehow restore it (after we discover
what broke, which might take time). And who knows what new complexity
that will bring us. But even if overall it means simplification, the
energy invested in that is not free, and could be used in other areas
of Emacs, where ROI is higher.
> > I agree, but when dealing with old and very complex code that
> > thousands of programs rely upon, we need to consider the risks of
> > changing the old behavior even if it is somewhat inconsistent.
> > Because sometimes an old, known, and minor problem is better than new,
> > unknown, and exciting ones.
>
> Yes, and for cases in which we're changing user-visible semantics in a
> way that'll break workflows --- like beginning-of-defun, perhaps ---
> then I agree with you. I don't think this particular change belongs to
> that category.
Not sure I follow: response to keyboard input and C-g is pretty much
in users' faces. Changes in it could well break workflows, when C-g
has special meanings, like in C-s.
> I've looked for evidence that would change my mind and
> haven't found any yet. You're right that changes to the input loop are
> risky, but they're going to be necessary sooner or later anyway, so
> wouldn't you prefer to change simpler code?
>
> Along the same lines, we could get rid of getcjmp too. I'm not afraid
> of rationalizing the contract of read-event or tweaking any other part
> of keyboard.c, but that thing and quit_throw_to_read_char are extremely
> confusing and do scare me a bit --- all the more reason, in my mind, to
> get rid of them, like Gerd wanted to do years ago. When is the right
> time to do that? It's not like an Emacs 31 release is imminent.
It depends how you interpret "imminent". Once Emacs 30.2 is released
(which should be soon), the emacs-31 release branch will be cut soon
afterwards, and development of Emacs 31 is basically frozen after
that, only bug fixes and last-minute changes of existing features are
allowed. Fingers crossed, that should happen in 3 or 4 months. The
release itself is probably at least 6 months after that, but we can no
longer make breaking changes during that period.
This bug report was last modified 4 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.