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

Previous Next

Full log

Message #68 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: Wed, 11 Jun 2025 17:29:48 +0300

> 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:08:45 -0700
> 
> Why is it good that read-key-sequence swallows quits but not read-char?

I don't know.  No one does.  maybe there's a good reason for it, maybe
there was one at some point but there isn't anymore, maybe it's just a
historical accident.

But being unable to answer such questions doesn't mean changing the
behavior is safe.  It usually is the other way around, in a program as
old and complex as |Emacs.

> C-g is an event.  Why should read-event (but not read-key-sequence?)
> translate one kind of input event (C-g) to an action (signal quit) but
> return other kinds of events as they're given?

You consider this to be an inconsistency based only on the name of the
API.  But that's not necessarily the whole contract of the API.  It
doesn't need to be called get-char-quit-when-c-g to behave like it
does.

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?

> What specifically do you think might break here?

Not in those toy examples, but in much larger programs where these are
used.

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.

> The higher level function wants to read an event.  That's exactly what
> this function does now.

How do we know that is all that's expected from it? just because its
name says so?

> > Sorry, we cannot assume that attitude, not in this case.  Making
> > incompatible behavior changes in this area means we will definitely
> > break enough use cases to cause a flood of bug reports.  We cannot do
> > that so freely and nonchalantly.  We could perhaps make it an optional
> > behavior, but that's all.
> >
> > I appreciate the urge to fix what you perceive as inconsistencies, but
> > that alone doesn't IMO justify risky incompatible changes in default
> > behavior, especially if they leave no "fire escape".  Please
> > understand where I stand on this.  This position isn't arbitrary, it
> > is based on our experience from making changes in this area in the
> > recent years.
> 
> We can't just avoid changing things because we don't understand the
> code.  I put a fair bit of time into understanding this code, and that
> means

I didn't say we cannot make changes there.  I said we should be very
cautious if and when we do.  Which means:

 . we should think hard and then think again whether the change is
   really necessary and how important are the problems that it solves
   or new features it allows
 . we should have a knob to revert to previous behavior

> > We could also leave the old behavior alone.  It isn't bad behavior.
> 
> 
> So you're saying it's a good thing that the behavior of the code changes
> depending on whether it's compiled?

No, I'm saying that in this case it could be minor enough and rare
enough to fail to outweigh the risks.

> This whole area is full of bugs.  Are we seriously in "fixing bugs is
> bad because something might change" territory?  In a development branch?
> With a knob (for now) to revert to the old, broken behavior?

See above: that's not what I'm saying.

> One way to make the code more understandable is to
> make it consistent and clearly define its contract.  When code has a
> regular structure, you don't need to keep a thousand special cases in
> your mind when working on it.  Regularity allows you to substitute
> reason for memory.  The code is pretty irregular right now.

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.

Previous Next

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