Re: Confused by y-or-n-p

[Gregory Heytings]

> > I am proposing a systematic way to make them less likely, by helping 
> > people take notice that a UI change is being proposed, so they can 
> > object quickly.
>
> In most cases, the reaction to UI changes is to complain about the 
> change because it's ... different.  That makes for very poor arguments, 
> *especially* when the change is discussed without people having actually 
> tried it out for a while to see how it plays out in practice after the 
> initial "bump".

I agree with you, but I think you are missing Richard's main point: any 
significant UI change should either require setting a variable, or provide 
a way to disable the new behavior / re-enable to old behavior.  Because it 
is always possible that, after having actually tried out a new behavior 
for a while, people dislike it.  For example because they use Emacs in a 
way that was not envisioned by the developer who implemented the UI 
change, and that this UI change breaks their configuration, which relied 
on the old behavior.

I can't speak for everyone, but I think one of the reasons people use and 
like Emacs is that it is stable.  Breaking its stability unavoidably 
creates frictions.

An simple and good example is the :extend attribute, which was added in 
Emacs 27.  People who liked the old behavior simply had to add an ":extend 
t" attribute to a number of faces in their configuration, and that's all.