[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changes for emacs 28
Re: Changes for emacs 28
Thu, 10 Sep 2020 22:16:42 +0300
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
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
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.
Re: Changes for emacs 28, Richard Stallman, 2020/09/08
Re: Changes for emacs 28, Philip K., 2020/09/10
Re: Changes for emacs 28, Tassilo Horn, 2020/09/11