Re: Changes for emacs 28

[Dmitry Gutov]

On 09.09.2020 17:04, Eli Zaretskii wrote:

> > On 08.09.2020 17:35, Eli Zaretskii wrote:
> > > See, that's exactly the crux of the difficulty in these matters: ask N
> > > people about changing defaults to M options, and you get the number of
> > > different "please do this and this, but not that" opinions almost as
> > > large as the number of permutations.
> >
> > Honestly, I don't think that enabling (or not) display-line-numbers-mode
> > is going to be a big deal either way: it's easy to enable or disable,
> > and it has little far-reaching consequences otherwise.
>
> That was only an example.
>
> And anyway, isn't what you say above true for almost every optional
> feature in Emacs?

For a lot of them, yes. But of course there are also changes in behavior 
(that people also asked for) that can have farther-reaching consequences.

So I do believe we shouldn't worry too much about making some existing 
users moderately unhappy if we have convincing data that a given change 
will make Emacs more useful or more approachable (without making it less 
useful) for a lot of users, current or future ones. Especially if said 
optional feature is easy to toggle, and we can document how to negate 
the change in NEWS.

Repeat the same decision process M times.

Since this way there is no goal of making every user 100% happy, there 
is no stalemate.

> > > So either (1) we go for the lowest common denominator of features that
> > > most people agree to (which can easily be an empty set); or (2) we
> > > come up with groups of optional features which are turned on and off
> > > together.
> >
> > Orthogonally, we could decide on a method for changing defaults which
> > doesn't involve the impossible task of making everybody happy but still
> > makes some effort to change with the times.
>
> If this can be done, why not?
> But based on past experience, I'm
> skeptical, to tell the truth.

From my past experience, what was lacking is direction in leadership. 
Sorry to be blunt.

There were cases where we had evidence that a change will be welcome by 
the majority of users, existing and potential ones, and would be easily 
reverted locally by anybody who didn't like it, and it still wasn't 
made. E.g. the simple case of indent-tabs-mode=>nil.

Of course, not all cases are simple, and whether something is generally 
beneficial/user-friendly/etc is a matter of judgment. But at least we 
shouldn't be stopped by the sole concern that a given change can 
generate complaints because the option in question has held a certain 
value for a number of years. Or even decades.