bug#30462: flyspell-auto-correct-word 'corrects' more than the current word

[Eli Zaretskii]

> Cc: 30462@debbugs.gnu.org, jidanni@jidanni.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 16 Feb 2018 13:36:32 +0200
> 
> On 2/16/18 12:55 PM, Eli Zaretskii wrote:
> 
> > I see your point, but I think the number of years we had this has
> > greater weight.
> 
> This can be an argument for choosing between the ways to fix something, 
> but not to just give up.

I'm not against a fix, I'm just saying that the fix should not change
the default behavior in totally incompatible ways.

> It's not like an API stability argument, no third-party Lisp code will 
> break after this change.

I don't see why breaking someone's code is deemed more serious than
breaking someone muscle memory and habits of using Emacs for many
years (this code is in Emacs since July 2000!).  To me, they are
equally bad.

> >> Is it really that important in this case? We're allowed to change the
> >> defaults from time to time.
> > 
> > Based on only one complaint, after all these years?  I don't think so.
> 
> That's a valid rebuke, but I imagine the total number of users is not 
> very high either. Especially of those who rely on the possibility of 
> auto-correcting far-away words.

We have no way of knowing that, and in any case having someone come up
in the future with a legitimate question of why did we change this
behavior "just like that" is not a prospect I like, unless e have a
very good answer.  Which in this case we don't, not IMO.

> > IMO, we must maintain stable UI and defaults in Emacs, after so many
> > years.
> 
> What about improving the UI?

We do that all the time, but we do that in backward-compatible ways.
Or at least we try.

> If stability to such high degree is the goal, Emacs will more likely 
> fade away together with the current generations of its users.

That's unfair, and also a kind of strawman.  Emacs evolves by adding
new features, much more than by changing the existing ones.  New
features don't have the "past performance" baggage, so we are free to
design and implement them as we see fit.  We can also change existing
features, as long as the deviant behavior, when first introduced, is
opt-in and doesn't change the long-standing defaults.

So stability in veteran features and APIs doesn't mean stagnation, far
from it.

I really don't understand why we are still arguing.  I already said
that it's okay to make this feature optional, provided that its
default remains as it is today.  Why would someone insist on changing
the default for _everyone_ if they can have it customizable for
themselves to their liking?