Re: Discussion about why GNU/Linux system upgrades cause old programs to break

> From: Arsen Arsenović <[email protected]>
> Cc: [email protected],  [email protected],  [email protected]
> Date: Sat, 15 Aug 2026 20:10:54 +0200
> 
> >> But, to make an analogous hypothetical for sake of clarity, if Emacs was
> >> to change some default because you, a veteran Emacs developer, with
> >> consensus from other Emacs developers, saw that it has caused much more
> >> harm than good, and it happened to break some random Elisp script on my
> >> machine, that went untouched for 25 years, but helped a thousand people
> >> for each such script, would you expect me to use it as an example of the
> >> poor judgment, abandonment of principle, carelessness, and adversarial
> >> approach of you, a few years down the line?
> >
> > YES!  When such changes are suggested for Emacs, there's no end to our
> > attempts to find a way to have the cake and eat it, too, so that we
> > don't break backward compatibility.  You can find many examples of
> > that on this list.  In many cases, when a solution that leaves both
> > cases satisfied cannot be found, we actually refuse to make the
> > change, even though the proposed new behavior is desirable.
> >
> >> Would it be fair for me to say, in that scenario, "that the current
> >> attitude of many/most Emacs developers is at best downplaying the
> >> importance of being able to run old Elisp, and at worst is utterly
> >> hostile to the plight of people who for some reason need to do that"?
> >
> > YES!!!
> >
> >> I don't read debbugs for Emacs.  I don't maintain ELPA.  I don't
> >> maintain Emacs core.  How could I possibly allow myself to do that?
> >
> > You can allow that because your legitimate use case was broken by a
> > change in Emacs.
> 
> I don't think you're being frank here.  It's easy to be bold in face of
> a hypothetical.

It isn't a hypothetical.  I invite you to read this list and the
bug-gnu-emacs list, and you will see it for yourself.

> The example below demonstrates this.  You've "mov[ed] towards
> [lexical-binding:t by default] painstakingly slowly", so you think it's
> OK.  Yet, when an aged exception made for backwards compatibility is
> reconsidered 20 (or more) years later, after a diagnostic has been
> emitted for that scenario the entire time, you think that's not OK.

Sorry, you lost me here.  I don't understand what you are saying.

> I can conjure up programs that will break after the lexical-binding
> change.  Indeed, I can probably find programs that will break after that
> change, rather than needing to construct one.

That didn't happen yet, so let's delay this until it does, so we could
talk about something that has a factual basis.  How about if you find
another example, something that we actually did in Emacs?

> >> For instance, it may happen when lexical-binding becomes default.
> >
> > Which is why we are moving towards that goal painstakingly slowly, in
> > tiny steps, each time leaving behind compatibility features and
> > waiting a very long time between such changes.  Several people brought
> > up suggestions to move faster and with bolder changes, but we
> > eventually decided not to do that.
> 
> The K&R C diagnostics have been in place for C99 and newer since at
> least 2004 (I don't have GCCs older than that on hand).  GCC started
> emitting them without any flags set in 2015, when C11 became the default
> dialect.  They only started being rejected by default in 2024, with a
> way to get old behaviour back.
> 
> In fact, even back in 2004, there was a way to suppress those
> diagnostics.  There still is.
> 
> Like with that change, the change of the lexical-binding default will,
> should it happen, break programs.
> 
> Based on this, it seems to me that there's a double standard at play.

Is there?  lexical-binding was introduced in Emacs 24.1, released in
2012, and it isn't default yet.  So let's defer the discussion of
whose double standard it is until lexical-binding becomes the default
in Emacs, so we could compare the actual, not hypothetical, timelines,
okay?

> > It was not wrong once upon a time.  And programs still worked and did
> > their jobs correctly.  Yes, that required the developers to be more
> > vigilant and find problems "by hand" rather than with help of the
> > compiler.  But that's a far cry from "blatantly wrong".
> 
> No, a program that called a function returning a pointer as if it was
> returning an int was wrong once upon a time also, and would indeed break
> sporadically on machines whee the sizes of integers and pointers differ,
> even if we're lucky enough not to see it break in other ways.

Buggy programs happen under C99 as well, so that's a red herring.

> With that context, I asked: should malloc development have halted even
> though pdumper was made?

They moved on even before that.

> (Yes, I know that would not have happened, but "will avoid breaking
>  Emacs [...] at all costs" implies that it should have.  I doubt you
>  mean that.
> 
>  This also seems very un-comradery; it implies that Emacs concerns
>  should triumph over all others, and implies that Emacs specifically
>  cannot be wrong in using other GNU tools.

Emacs does not consciously break other GNU projects, so there's
nothing un-comradery here.  The attitude is symmetrical.

Anyway, since it sounds like we are down to discussing whether Emacs
is better or worse than other GNU projects, I will bow out of this now
useless "discussion".