Re: Confused by y-or-n-p

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 07 Jan 2021 23:34:09 +0000
> From: Gregory Heytings <ghe@sdf.org>
> cc: stefankangas@gmail.com, monnier@iro.umontreal.ca, rudalics@gmx.at,
>         emacs-devel@gnu.org, rms@gnu.org, juri@linkov.net
> 
> 
> >> It is happening in the "Stop frames stealing each other's minibuffers" 
> >> thread
> >
> > No, it doesn't.  In fact, the exact opposite happens there: an 
> > assumption that the existing behavior is a bug was later reversed based 
> > on feedback from you and others.
> 
> Alas, this is not what is happening there.  The old behavior has been 
> lost, and the developer who initiated these changes still firmly believes 
> that the old behavior is "an ad hoc unsystematic mess, not worthy even of 
> being called a behaviour", that it is "chaotic", that it is an "abstruse 
> "design" [that] can only have arisen by accident", that it "would get 
> rejected out of hand, and indeed ridiculed" if it were proposed now.  In 
> spite of this, an approximation of the old behavior is now planned, and 
> I'm supposed to document where that current approximation differs from the 
> old behavior, to fix the current approximation.  There is of course no 
> chance that the behavior of an UI element as complex as the minibuffer 
> could ever be recovered by working that way.

There's no contradiction between what I said and what you say, when we
consider what happens in practice.  In practice Alan works on
providing an option to have the best approximation to past behavior
that is practical, given the extensive source code changes he has
done.  That is consistent with the "best effort" nature of providing
backward compatibility in such cases, so I'm okay with that.  We have
other cases where changes were so extensive that providing the 100%
backward-compatibility option is impractical.  (This is one reason why
a dogmatic rule for providing such options is something I cannot agree
to.)