bug#48249: 28.0.50; Regression: emacs confused about window configuration due to ido-mode and/or winner-mode

[Eli Zaretskii]

> Date: Thu, 06 May 2021 08:17:59 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 48249@debbugs.gnu.org, dima@secretsauce.net
> 
> > Significant changes in low-level infrastructure frequently cause a trail 
> > of unintended consequences that need to be fixed.
> 
> When a low-level infrastructure has worked flawlessly for more than a 
> decade, making significant changes in it without making them conditional 
> to a run-time variable or a compilation option, until the new code is 
> "proven" enough, is unwise.

First, a knob to control new code is not always possible, though I
agree it is preferable when it's feasible.  In this case, we do have a
knob to control the new code, albeit not a knob that goes back to the
previous behavior with 100% accuracy.  It's possible that the OP
should try flipping that option, maybe it will work around the problem
(not that I think it's necessarily the solution).

More generally, that's development for you; without risking such
destabilization from time to time we can never afford significant
improvements.  The important question is: will the new-and-improved
behavior be useful or won't it?

> > If you think what we saw till now as result of that changeset is a 
> > catastrophe, you just didn't see enough serious low-level changes in 
> > Emacs yet.
> 
> Did other low-level changes in Emacs result in segfaults and several bug 
> reports of confused users each week?  I'd hope not.

Yes, of course.  The introduction of bidirectional editing support
during development of Emacs 24.1 comes to mind.  Like I said: stick
around some more, and you will see more examples.

Emacs 28.1 is still many moons away.  We will figure this out till
then, don't worry.