unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 30462@debbugs.gnu.org, jidanni@jidanni.org
Subject: bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
Date: Tue, 20 Feb 2018 02:51:17 +0200	[thread overview]
Message-ID: <f50d7d59-0644-db0f-efef-bed4a0c4af77@yandex.ru> (raw)
In-Reply-To: <83606xdp1m.fsf@gnu.org>

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.





  parent reply	other threads:[~2018-02-20  0:51 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-15  6:24 bug#30462: flyspell-auto-correct-word 'corrects' more than the current word 積丹尼 Dan Jacobson
2018-02-15 12:00 ` Eli Zaretskii
2018-02-15 12:56   ` 積丹尼 Dan Jacobson
2018-02-15 16:56     ` Eli Zaretskii
2018-02-16  0:22       ` 積丹尼 Dan Jacobson
2018-02-16 10:15       ` Dmitry Gutov
2018-02-16 10:55         ` Eli Zaretskii
2018-02-16 11:03           ` 積丹尼 Dan Jacobson
2018-02-16 11:36           ` Dmitry Gutov
2018-02-16 13:47             ` Eli Zaretskii
2018-02-16 14:18               ` Eli Zaretskii
2018-02-16 14:33                 ` Eli Zaretskii
2018-02-17  0:58                   ` 積丹尼 Dan Jacobson
2018-02-17  7:47                     ` Eli Zaretskii
2018-02-17 11:43                       ` 積丹尼 Dan Jacobson
2018-02-17 14:51                       ` 積丹尼 Dan Jacobson
2018-02-17 15:13                       ` 積丹尼 Dan Jacobson
2018-02-17 16:09                         ` Eli Zaretskii
2018-02-17 23:37                           ` 積丹尼 Dan Jacobson
2018-02-20  0:24                           ` Dmitry Gutov
2018-02-20  4:08                             ` Eli Zaretskii
2018-03-03 10:49                               ` Eli Zaretskii
2018-02-20  0:28                 ` Dmitry Gutov
2018-02-20  4:24                   ` Eli Zaretskii
2018-02-20 11:38                     ` Dmitry Gutov
2018-02-20 17:57                       ` 積丹尼 Dan Jacobson
2018-02-20  0:51               ` Dmitry Gutov [this message]
2018-02-18  0:14   ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f50d7d59-0644-db0f-efef-bed4a0c4af77@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=30462@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=jidanni@jidanni.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).