Re: [PATCH] Only signal package.el warnings when needed

[Eli Zaretskii <eliz@gnu.org>]

> From: Radon Rosborough <radon.neon@gmail.com>
> Date: Mon, 21 Jan 2019 14:45:36 -0800
> Cc: emacs-devel <emacs-devel@gnu.org>
> 
> > That there's some fallout cannot be used as an ultimate argument in
> > favor or against some change.
> 
> In that case, could you explain what /would/ be a good argument in
> favor or against the change I am proposing? As far as I can tell, it
> saves people time without any known disadvantages (and with very
> little additional complexity -- the patch being about 70 lines of
> code), but you don't seem to consider this a good enough argument.

There's no argument between us about the advantages of the proposed
change.  The argument seems to be about the disadvantages, and
specifically about the risks of unintended consequences of changes in
this area.  The size and the complexity of the patch is therefore not
the important indicator, what's important is the complexity of the
code which it changes, and the associated risk of unintentionally
breaking some important use case out there, of which there are quite a
few.

I realize that you don't necessarily agree with this POV, but we have
different perspectives on this.

> > > If we wait until Emacs 27.2 to fix the complaints, then it will
> > > already be too late to do anything useful.
> >
> > That was the situation before the recent changes, and we still made
> > those changes.
> 
> I don't see why this would be an argument against the change I am
> proposing.

It isn't.  It is an argument against the haste of making changes
because it might be "too late" afterwards.  I'm saying that we are not
afraid of making changes afterwards, and I provided an example of
that, one that you should be familiar with.

> The recent changes were useful, which is why we made them,
> but they would have been even /more/ useful if we had made them
> earlier (before everyone's init-files got changed).

Fixing problems sooner rather than later is always an advantage.  But
it should be weighed against any disadvantages, and in this case it
seems to me that we might not yet have enough experience with the
current code to design a solution whose risks are low enough.

> > So maybe the right solution is to make that variable public instead.
> 
> Maybe. But this seems like a strictly inferior solution from the
> perspective of user experience, since it still results in users being
> shown superfluous warnings which waste their time and mental effort.

It might be a stopgap, but if it improves the situation while running
lower risks, it could be a good interim measure.