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

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

[積丹尼 Dan Jacobson]

    C-M-i (translated from <escape> <tab>) runs the command
    flyspell-auto-correct-word (found in flyspell-mode-map), which is an
    interactive compiled Lisp function in ‘flyspell.el’.

    It is bound to C-., C-M-i.

    (flyspell-auto-correct-word)

    Correct the current word.
    This command proposes various successive corrections for the current word.

Well it turns out if the current word is already correct, then it
searches backward up to several sentences looking for another word that
it can correct.

Which can have disastrous consequences when the boss reads the final
draft of what you sent him.

Therefore it would be best if this command would limit its helpfulness
to what it says in the docstring: the current word.

Which to me means not some word 30 words back.

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

[Eli Zaretskii]

On February 15, 2018 8:24:25 AM GMT+02:00, "積丹尼 Dan Jacobson" <jidanni@jidanni.org> wrote:
>     C-M-i (translated from <escape> <tab>) runs the command
>   flyspell-auto-correct-word (found in flyspell-mode-map), which is an
>     interactive compiled Lisp function in ‘flyspell.el’.
> 
>     It is bound to C-., C-M-i.
> 
>     (flyspell-auto-correct-word)
> 
>     Correct the current word.
> This command proposes various successive corrections for the current
> word.
> 
> Well it turns out if the current word is already correct, then it
> searches backward up to several sentences looking for another word
> that
> it can correct.
> 
> Which can have disastrous consequences when the boss reads the final
> draft of what you sent him.
> 
> Therefore it would be best if this command would limit its helpfulness
> to what it says in the docstring: the current word.
> 
> Which to me means not some word 30 words back.

This happens only if you invoke the command more than once on the same
location.  So, while I agree that the doc string should be fixed, the problem
you describe can happen only by user request.

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

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
EZ> This happens only if you invoke the command more than once on the same
EZ> location.  So, while I agree that the doc string should be fixed, the problem
EZ> you describe can happen only by user request.

Luckily I noticed the 97th word in the 35th paragraph was subtly
changing itself. So I was lucky I was a bad speller.

If I was a good speller it would have probably got to work on some other
word even more paragraphs back way off the screen. Turing a misspelled
mother into monster...

I would respectfully say fix it to act like its documentation.

And make reaching into the dark corners of your document that you are
not aware of and changing words ... into a non-default bonus feature...
or move it into M-x dissociated-press.

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

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: bug-gnu-emacs@gnu.org, 30462@debbugs.gnu.org
> Date: Thu, 15 Feb 2018 20:56:17 +0800
> 
> >>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
> EZ> This happens only if you invoke the command more than once on the same
> EZ> location.  So, while I agree that the doc string should be fixed, the problem
> EZ> you describe can happen only by user request.
> 
> Luckily I noticed the 97th word in the 35th paragraph was subtly
> changing itself. So I was lucky I was a bad speller.
> 
> If I was a good speller it would have probably got to work on some other
> word even more paragraphs back way off the screen. Turing a misspelled
> mother into monster...

Sorry, I don't understand.  My point was that typing C-M-i or C-. once
on a correctly spelled word doesn't try to change any other words in
the buffer.  Flyspell only does that if you invoke that command more
than once.

Are you saying that it happened to you when you invoked the command
only once?  That would be a bug, but then please describe a recipe for
reproducing it, because I don't see it here.

> I would respectfully say fix it to act like its documentation.

That would change its long-standing behavior in incompatible ways, so
I don't think we can do that.

> And make reaching into the dark corners of your document that you are
> not aware of and changing words ... into a non-default bonus feature...
> or move it into M-x dissociated-press.

I'm okay with making this behavior optional, but it will have to be on
by default, for backward compatibility.

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

[積丹尼 Dan Jacobson]

EZ> Sorry, I don't understand.  My point was that typing C-M-i or C-. once
EZ> on a correctly spelled word doesn't try to change any other words in
EZ> the buffer.  Flyspell only does that if you invoke that command more
EZ> than once.

The problem is the user might think a word is misspelled and start
hitting the command. After a hit or two he starts to notice the word
isn't changing, or in fact hasn't changed at all.

He thinks, "oh yeah, I spelled it right in the first place, ha ha." And
goes back to his work -- little realizing that way back in the 22nd
paragraph of the 39th clause in the contract he is writing Oxfam has
been changed to Exam etc. etc.

EZ> I'm okay with making this behavior optional, but it will have to be on
EZ> by default, for backward compatibility.

Or have it warn: you are about to change some word that might not even
be on this page. OK just once? Always? Never?

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

[Dmitry Gutov]

On 2/15/18 7:56 PM, Eli Zaretskii wrote:

>> I would respectfully say fix it to act like its documentation.
> 
> That would change its long-standing behavior in incompatible ways, so
> I don't think we can do that.

I respectfully disagree. The current behavior is both undocumented and 
dangerous.

>> And make reaching into the dark corners of your document that you are
>> not aware of and changing words ... into a non-default bonus feature...
>> or move it into M-x dissociated-press.
> 
> I'm okay with making this behavior optional, but it will have to be on
> by default, for backward compatibility.

Is it really that important in this case? We're allowed to change the 
defaults from time to time.

And having C-M-i (bound to completion-at-point in most other contexts) 
do something like this is a bad UI.

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

[Eli Zaretskii]

> Cc: 30462@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 16 Feb 2018 12:15:52 +0200
> 
> On 2/15/18 7:56 PM, Eli Zaretskii wrote:
> 
> >> I would respectfully say fix it to act like its documentation.
> > 
> > That would change its long-standing behavior in incompatible ways, so
> > I don't think we can do that.
> 
> I respectfully disagree. The current behavior is both undocumented and 
> dangerous.

I see your point, but I think the number of years we had this has
greater weight.

> > I'm okay with making this behavior optional, but it will have to be on
> > by default, for backward compatibility.
> 
> 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.

> And having C-M-i (bound to completion-at-point in most other contexts) 
> do something like this is a bad UI.

That ship has sailed a long time ago, so again long-time practice
wins.

IMO, we must maintain stable UI and defaults in Emacs, after so many
years.

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

[積丹尼 Dan Jacobson]

EZ> Based on only one complaint, after all these years?  I don't think so.

That's because most people don't notice it has tinkered with some word
way back in chapter three off the screen... until it is too late.
Conclusion: don't edit anything important, like the U.S. Constitution.

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

[Dmitry Gutov]

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.

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

>> 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.

>> And having C-M-i (bound to completion-at-point in most other contexts)
>> do something like this is a bad UI.
> 
> That ship has sailed a long time ago, so again long-time practice
> wins.
> 
> IMO, we must maintain stable UI and defaults in Emacs, after so many
> years.

What about improving the UI? It's not like it has reached perfection at 
any time.

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

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?

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

[Eli Zaretskii]

> Date: Fri, 16 Feb 2018 15:47:33 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 30462@debbugs.gnu.org, jidanni@jidanni.org
> 
> I'm not against a fix, I'm just saying that the fix should not change
> the default behavior in totally incompatible ways.

Actually, I seem to be unable to reproduce this now, no matter how
hard I try.  I swear I saw the reported behavior when I first tried
that, but now all I see is flyspell-auto-correct-word cycling between
possible correction candidates, and doing nothing if the word is
spelled correctly.  I wonder what am I missing.

So please provide an exact recipe for reproducing the problem,
including the text you have in the buffer and the speller/dictionary
you use, and also please tell what Emacs version are you using.

In the meantime I'm going to fix the doc string to describe the
behavior when the command is invoked at the same location repeatedly.

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

[Eli Zaretskii]

> Date: Fri, 16 Feb 2018 16:18:59 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 30462@debbugs.gnu.org, dgutov@yandex.ru
> 
> Actually, I seem to be unable to reproduce this now, no matter how
> hard I try.  I swear I saw the reported behavior when I first tried
> that, but now all I see is flyspell-auto-correct-word cycling between
> possible correction candidates, and doing nothing if the word is
> spelled correctly.  I wonder what am I missing.

Maybe your problem happened in a buffer which mixed text of 2 or more
different languages, and the closest word that matched your current
dictionary's language was far away before point?

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

[積丹尼 Dan Jacobson]

Yes many different factors combined so reproduction is a matter of luck
for your or me too. All the more reason to warn upon dangerous actions.

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

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: 30462@debbugs.gnu.org,  dgutov@yandex.ru
> Date: Sat, 17 Feb 2018 08:58:57 +0800
> 
> Yes many different factors combined so reproduction is a matter of luck
> for your or me too. All the more reason to warn upon dangerous actions.

Is it possible for you to provide a recipe which would allow such
reproduction?  I think it's important to have the problem completely
understood before we discuss how to fix it.  (Previously, I thought I
did understand it, but that turned out to be a fallacy.)

Dmitry, do you see the problem?  If so, perhaps you can help with a
recipe?

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

[積丹尼 Dan Jacobson]

>>>>> "EZ" == Eli Zaretskii <eliz@gnu.org> writes:
EZ> Is it possible for you to provide a recipe which would allow such
EZ> reproduction?  I think it's important to have the problem completely
EZ> understood before we discuss how to fix it.  (Previously, I thought I
EZ> did understand it, but that turned out to be a fallacy.)

All I know is just now it changed my username to "jinni".
Good thing my eye caught it, only a few words back.

I was editing this buffer:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
> To:                                                                                  >
> Subject:                                                                             >
> Date: Sat, 17 Feb 2018 19:11:22 +0800                                                >
> Message-ID: <871shjlvl1.fsf@jidanni.org>                                             >
> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>                                      >
> --text follows this line--                                                           >
> There is no mechanism in place to ever detect                                        >
> ~/.josm/cache/                                                                       >
>                                                                                      >
>   -rw-r--r-- 1 jinni 728037 2013-04-18   <MY CURSOR WAS NEAR HERE>                   >
>                                                                                      >
> mirror_http___josm.openstreetmap.de_maps                                             >
>   -rw-r--r-- 1 jidanni 3546155 02-16 09:46 mirror_https___josm.openstreetmap.de_maps >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >

And was typing this:

 r r [self-insert-command]
 SPC SPC [self-insert-command]
 d [self-insert-command]
 e e [self-insert-command]
 t t [self-insert-command]
 e e [self-insert-command]
 c c [self-insert-command]
 t t [self-insert-command]
 C-n [next-line]
 C-n [next-line]
 C-n [next-line]
 C-b [backward-char]
 C-b [backward-char]
 C-b [backward-char]
 SPC [self-insert-command]
 C-o [open-line]
 C-o [open-line]
 C-. [flyspell-auto-correct-word]
 C-d [delete-char]
 C-/ C-/ [undo]
 C-h l [view-lossage]

I see my .emacs already has
;;Two flyspell keys too close to C-/ undo:
(global-unset-key (kbd "C-."))
(global-unset-key (kbd "C-,"))
etc. (But of course that is not good enough.)

And indeed I would have never hit either on purpose, only by accident.

When I really want to use flyspell-auto-correct-word I always use C-M-i,
not C-. .

And you know what,
no matter what I put into .emacs,

(eval-after-load "flyspell-mode"
  '(add-hook
    'flyspell-mode-hook
    (lambda ()
      ;;too close to C-/ (undo) and already on ESC TAB:
;     (define-key flyspell-mode-map [(control ?\.)] [])
     (define-key flyspell-mode-map (kbd "C-,") (lambda () (interactive)))
     (define-key flyspell-mode-map (kbd "C-.") (lambda () (interactive)))
     )))

I just can't unbind them.

They are un-unbinable.

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

[積丹尼 Dan Jacobson]

And now that I have become more sensitive to the bug, I notice it just
happened again:

OK now today I was really trying to use flyspell-auto-correct-word,
but my cursor happened to be just past the "t" below.

As there really isn't much spelling to be corrected at "t", I started
noticing in the minibuffer (*Message* buffer):

Auto-saving...done
Corrections: unkind unkinder antonym inking envenom uncanny unkonwm unknown unkind
Corrections: unkinder antonym inking envenom uncanny unkonwm unknown unkind unkinder
Corrections: antonym inking envenom uncanny unkonwm unknown unkind unkinder antonym
Auto-saving...


> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
> Shall we do as we do now, and just let it sail through,                >
> ```                                                                    >
> http://a.b.c?xzzz{Header,Dont-Let-Larry-Know,Yes}                      >
> ```                                                                    >
>                                                                        >
> No. We not only let Larry know, we let him know we didn't want to let  >
> him know. Our user will doubly hunt you down, if Larry doesn't get him >
> first.                                                                 >
>                                                                        >
> Indeed, that is just like when we know what ftp://x and http://y are,  >
> but not irc://z . So irc://z must mean http://irc://z . That is about  >
> how much little sense it makes.                                        >
>                                                                        >
> So what should we do?                                                  >
>                                                                        >
> We should not let the request go over the wires in the first place.    >
>                                                                        >
> Instead we should tell the user to fix thier t<MY CURSOR IS HERE>      >
> print out an error message                                             >
> : E.g.,                                                                >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >

 t [self-insert-command]
 e e [self-insert-command]
 h h [self-insert-command]
 <backspace> <backspace> [delete-backward-char]
 <backspace> <backspace> [delete-backward-char]
 h h [self-insert-command]
 i i [self-insert-command]
 e e [self-insert-command]
 r r [self-insert-command]
 SPC SPC [self-insert-command]
 t [self-insert-command]
 e e [self-insert-command]
 m m [self-insert-command]
 <backspace> <backspace> [delete-backward-char]
 <backspace> <backspace> [delete-backward-char]
 <escape> <escape> <tab> [flyspell-auto-correct-word]
 <escape> <tab> [flyspell-auto-correct-word]
 <escape> <tab> [flyspell-auto-correct-word]
 <escape> <tab> [flyspell-auto-correct-word]
 C-x C-b [list-buffers]

OK as I didn't notice anything change (that's why I hit
flyspell-auto-correct-word the second etc. times, to see what it was up
to, where.)

So obviously those "Corrections: unkind unkinder..." mean that it was
indeed changing something off the screen and I will have to proofread
the entire draft to hopefully find where.
You might say "just use undo", but one fears that might even mess things
up further, so we chicken out.

P.S., one would think "just run a spell checker on your article."
Well that only detects misspelled words and where ever that word was,
alas, it is no longer misspelled now.

Wait (via searching for the last word in the last *Message* I found it,

> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>            >
> --text follows this line--                                 >
> Don't let antonym WMS URL template directives sail through >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
That's right, way at the top of the message (way off the top of the
screen)  I was composing, it changed some word into "antonym".

Thank goodness I can run "undo" on just a region, revealing the original,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
> Don't let unknown WMS URL template directives sail through >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >

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

[積丹尼 Dan Jacobson]

[-- Attachment #1: Type: text/plain, Size: 40 bytes --]

Put your cursor at the end of this file

[-- Attachment #2: test file --]
[-- Type: application/gzip, Size: 1773 bytes --]

[-- Attachment #3: Type: text/plain, Size: 129 bytes --]

after the "thier t".
Now hit some ESC TABs.
Notice how way off the screen near the top, "theww" is mutating further and further.

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

[Eli Zaretskii]

> From: 積丹尼 Dan Jacobson <jidanni@jidanni.org>
> Cc: 30462@debbugs.gnu.org,  dgutov@yandex.ru
> Date: Sat, 17 Feb 2018 23:13:11 +0800
> 
> after the "thier t".
> Now hit some ESC TABs.
> Notice how way off the screen near the top, "theww" is mutating further and further.

But if you kill the buffer, then create a new one, insert the same
text into it, activate flyspell-mode, and try ESC TAB at the same
place, you won't see the problem, right?

I think I see the reason for this: it's a stale cache from a previous
invocation of flyspell-auto-correct-word that is not flushed when you
type more text or move point.  So flyspell-auto-correct-word tries to
correct the same word het time you invoke it, no matter how far away
are you.

Please try the patch below (you will need to byte-compile flyspell.el
after applying the patch).  If it gives good results, please run with
it for a while and see if there are any problems left.  If this change
has no adverse effects, I will push it.

diff --git a/lisp/textmodes/flyspell.el b/lisp/textmodes/flyspell.el
index 5568bbb..2187766 100644
--- a/lisp/textmodes/flyspell.el
+++ b/lisp/textmodes/flyspell.el
@@ -1933,6 +1933,8 @@ flyspell-auto-correct-word
       (call-interactively flyspell--prev-meta-tab-binding)
     (let ((pos     (point))
           (old-max (point-max)))
+      (if (not (eq last-command 'flyspell-auto-correct-word))
+        (setq flyspell-auto-correct-region nil))
       ;; Use the correct dictionary.
       (flyspell-accept-buffer-local-defs)
       (if (and (eq flyspell-auto-correct-pos pos)

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

[積丹尼 Dan Jacobson]

OK thanks. I'll try the patch in a few moments, but there is just one
more thing I want to say... which exposes a bug in view-lossage... but
probably even deeper...

 b [self-insert-command]
 e e [self-insert-command]
 h h [self-insert-command]
 a a [self-insert-command]
 v v [self-insert-command]
 u u [self-insert-command]
 o o [self-insert-command]
 u u [self-insert-command]
 <backspace> <backspace> [delete-backward-char]
 <backspace> <backspace> [delete-backward-char]
 <backspace> <backspace> [delete-backward-char]
 i i [self-insert-command]
 o o [self-insert-command]
 r r [self-insert-command]
 <escape> <escape> <tab> [flyspell-auto-correct-word]
 C-e [move-end-of-line]
 C-h l [view-lossage]

Uh oh, what did it correct this time? I thought it might have changed
behaviour into behavior like I wished. But looking closely, I had
already in fact typed behavior... So instead it probably went on one of
its long hunting missions... uh oh. Hmmm, checking *Messages* doesn't
show any of its usual choices...

Sure, blame me for trying to correct an already correct word.
But just like two wrongs don't make a right, two rights shouldn't make a
wrong.

No I don't know why lossage shows two

ABCdef
abcdef

I just tried an experiment.
Typing exactly eight characters, a b c ESC TAB d e f

C-h l runs the command view-lossage. It says

 a [self-insert-command]
 b b [self-insert-command]
 c c [self-insert-command]
 <escape> <escape> <tab> [flyspell-auto-correct-word]
 d [self-insert-command]
 e e [self-insert-command]
 f f [self-insert-command]

It shows two <escape>s !

Now let's try a real a b c ESC ESC TAB d e f
 a [self-insert-command]
 b b [self-insert-command]
 c c [self-insert-command]
 <escape> <escape> <escape> <tab> [nil]
 d [self-insert-command]
 e e [self-insert-command]
 f f [self-insert-command]

Three <escape>s!

Only this flyspell stuff is affected. Other ESC commands have OK lossage:

 <escape> g [goto-line]
 9 [self-insert-command]
 9 [self-insert-command]
 <return> [exit-minibuffer]

 <escape> x [execute-extended-command]
 w [self-insert-command]
 h [self-insert-command]
 o [self-insert-command]...

No wonder I can't unbind flyspell-auto-correct-word... it's on some
astral plane...

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

[Dmitry Gutov]

On 2/17/18 6:09 PM, Eli Zaretskii wrote:

> I think I see the reason for this: it's a stale cache from a previous
> invocation of flyspell-auto-correct-word that is not flushed when you
> type more text or move point.  So flyspell-auto-correct-word tries to
> correct the same word het time you invoke it, no matter how far away
> are you.

So it seems like it was an implementation accident after all (i.e. a 
bug), rather than a old behavior worth preserving.

> Please try the patch below (you will need to byte-compile flyspell.el
> after applying the patch).  If it gives good results, please run with
> it for a while and see if there are any problems left.  If this change
> has no adverse effects, I will push it.

It does fix the scenarios I could come up with. Looks like a good change 
to me, thanks!

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

[Eli Zaretskii]

> Cc: 30462@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 20 Feb 2018 02:24:32 +0200
> 
> On 2/17/18 6:09 PM, Eli Zaretskii wrote:
> 
> > I think I see the reason for this: it's a stale cache from a previous
> > invocation of flyspell-auto-correct-word that is not flushed when you
> > type more text or move point.  So flyspell-auto-correct-word tries to
> > correct the same word het time you invoke it, no matter how far away
> > are you.
> 
> So it seems like it was an implementation accident after all (i.e. a 
> bug), rather than a old behavior worth preserving.

Yes.  I somehow managed to get the problematic behavior on the first
attempt, and then misinterpreted the code which caused that.

> > Please try the patch below (you will need to byte-compile flyspell.el
> > after applying the patch).  If it gives good results, please run with
> > it for a while and see if there are any problems left.  If this change
> > has no adverse effects, I will push it.
> 
> It does fix the scenarios I could come up with. Looks like a good change 
> to me, thanks!

Thanks for testing.  I will wait a few more days before pushing.

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

[Eli Zaretskii]

> Date: Tue, 20 Feb 2018 06:08:26 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 30462@debbugs.gnu.org, jidanni@jidanni.org
> 
> > > Please try the patch below (you will need to byte-compile flyspell.el
> > > after applying the patch).  If it gives good results, please run with
> > > it for a while and see if there are any problems left.  If this change
> > > has no adverse effects, I will push it.
> > 
> > It does fix the scenarios I could come up with. Looks like a good change 
> > to me, thanks!
> 
> Thanks for testing.  I will wait a few more days before pushing.

Pushed to the release branch.

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

[Dmitry Gutov]

On 2/16/18 4:18 PM, Eli Zaretskii wrote:

> In the meantime I'm going to fix the doc string to describe the
> behavior when the command is invoked at the same location repeatedly.

The new docstring ways "at or near that position". You might or might 
not want to undo that.

The reason I'm unsure, though, is that flyspell is also happy to 
consider the word before point, even if it's separated with lots of 
whitespace. Maybe we should clarify what "current word" means for it 
instead.

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

[Eli Zaretskii]

> Cc: 30462@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 20 Feb 2018 02:28:40 +0200
> 
> On 2/16/18 4:18 PM, Eli Zaretskii wrote:
> 
> > In the meantime I'm going to fix the doc string to describe the
> > behavior when the command is invoked at the same location repeatedly.
> 
> The new docstring ways "at or near that position". You might or might 
> not want to undo that.

I tried to clarify that now.

> The reason I'm unsure, though, is that flyspell is also happy to 
> consider the word before point, even if it's separated with lots of 
> whitespace. Maybe we should clarify what "current word" means for it 
> instead.

That issue is inside flyspell-get-word, so I explained it in that
function's doc string, and added references to it to
flyspell-auto-correct-word and elsewhere.

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

[Dmitry Gutov]

On 2/20/18 6:24 AM, Eli Zaretskii wrote:

> That issue is inside flyspell-get-word, so I explained it in that
> function's doc string, and added references to it to
> flyspell-auto-correct-word and elsewhere.

Thanks!

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

[積丹尼 Dan Jacobson]

By the way, even with your patch view-lossage still sometimes says
 <escape> <tab> [flyspell-auto-correct-word] but also oddly sometimes says
 <escape> <escape> <tab> [flyspell-auto-correct-word]
even though I only ever pressed ESC once.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30462#65

And maybe that is related to me being unable to unbind C-. and C-,
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30462#53

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

[Dmitry Gutov]

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.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This happens only if you invoke the command more than once on the same
  > location.  So, while I agree that the doc string should be fixed, the problem
  > you describe can happen only by user request.

Yes and no.  Repeating a command again is an easy thing for a user to
do by mistake.

Since the effects may not be visible, person will not necessarily see
what has happened.  This is dangerous.  It should do some sort of
confirmation to protect per from this danger.

How about asking for confirmation the first time a user repeats
the command in this way?

-- 
Dr Richard Stallman
President, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Skype: No way! See https://stallman.org/skype.html.