bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
Date: Tue, 20 Feb 2018 02:51:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Thunderbird/59.0

On 2/16/18 3:47 PM, Eli Zaretskii wrote:

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

That was never the intention, I think.

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.

Someone's code might be used by a lot of users, whereas the muscle memory generally belongs only to one person. In certain situations, code can be harder to fix as well (or, at least, to make sure the fixed version reaches all its users).

And indeed, I think our policy has generally been that we can change a default key binding in the next release, but API-breaking Lisp changes have to go through periods of deprecation.

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.

"Danger of information loss" was a good reason, I believe. Anyway, I think we all agree it's a bug by now.

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.

When new and old can coexist, and the old is reasonably serviceable, sure.

Why would someone insist on changing
the default for _everyone_ if they can have it customizable for
themselves to their liking?

To answer this question in general: worry about new users (or just unaware ones) and Emacs's reputation.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]