GNU bug report logs - #30462
flyspell-auto-correct-word 'corrects' more than the current word

Previous Next

Full log

Message #77 received at 30462 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30462 <at> debbugs.gnu.org, jidanni <at> jidanni.org
Subject: Re: bug#30462: flyspell-auto-correct-word 'corrects' more than the
 current word
Date: Tue, 20 Feb 2018 02:51:17 +0200

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.