|
From: | Gregory Heytings |
Subject: | bug#48249: 28.0.50; Regression: emacs confused about window configuration due to ido-mode and/or winner-mode |
Date: | Thu, 06 May 2021 09:57:04 +0000 |
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.
It is _always_ possible. Whether through conditional compilation or through conditional code.
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).
Turning the knob doesn't work here, the bug occurs regardless of the value of that knob. Otherwise I would have mentioned that in my reply to Dima.
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?
Indeed perhaps the most important question here is: is this a "significant improvement"? IMO, the answer is clearly "no". Will this new behavior be "useful"? In this case I'd say "perhaps, for very few users, even though nobody requested it". But a marginal improvement that will benefit a few users is not worth taking the risk of unconditionally destabilizing old, time-proved code.
Yes, of course. The introduction of bidirectional editing support during development of Emacs 24.1 comes to mind.
That was, of course, a significant improvement that was worth taking the risk of destabilization.
[Prev in Thread] | Current Thread | [Next in Thread] |