Re: Confused by y-or-n-p

[Eli Zaretskii]

> Date: Mon, 04 Jan 2021 22:18:04 +0000
> Cc: emacs-devel@gnu.org
> From: Gregory Heytings via "Emacs development discussions." 
> <emacs-devel@gnu.org>
> 
>     I don't think that was Richard's point: we always go to great lengths to 
> make it possible to get back the old behavior (even for changes where the 
> impact is quite minor).
> 
>     E.g. with respect to `y-or-n-p`, I think we already all agree that there 
> should be a way to recover the previous "modal" behavior. We just need 
> someone to implement it (ideally while still preserving the improvement of 
> the new minibuffer-based code).
> 
> No always, alas.

Yes, not always.  It isn't feasible nor wise to do that "always", so
please don't insist on such unrealistic goals.  But in the vast
majority of cases, we do go to great lengths (some say too great) to
provide an option to get the old behavior back.  This list and the bug
list are replete with examples of that.

> With respect to y-or-n-p, there is now indeed an agreement that there should 
> be a way to recover the old behavior. But IIUC, Richard's point is that this 
> possibility should have been present since the beginning, when the new 
> behavior was introduced, without waiting for objections.

It is impossible to promise that no one will ever make good-faith
mistakes like this.  The important point is to have procedures in
place to detect such mistakes and fix them, without imposing too much
overhead on the development.

> What happened is (1) behavior A is removed and replaced by behavior B, (2) 
> enough people object this change, (2) behavior B is implemented again.
> 
> What could have happened instead is (1) behavior B is implemented, next to 
> behavior A, with a way to choose between them, (2) at some point, possibly 
> immediately, the default behavior is changed from A to B, (3) if after some 
> time it becomes clear that behavior A is not used anymore, it is deprecated, 
> and later again removed.

The changes in the process proposed for making such cases rarer would
cause a significant slowdown of the Emacs development, so my
conclusion is that those proposals are unjustified given the small
number of incidents that would presumably call for those changes.

> Having both behaviors available at the same time is also, I believe, a 
> necessary condition for a fruitful comparison and discussion. Otherwise the 
> discussion is about the merits of a removed behavior vs. the new behavior 
> instead of about the merits of a behavior A vs. a behavior B.

It is very easy to compare without having both behaviors in the same
binary: just keep old binaries around.  That's what I do, and it
allows me to quickly see what was past behavior, and even perform a
quick "bisection" when some new problem is reported.  Highly
recommended.