* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
@ 2018-02-15 6:24 積丹尼 Dan Jacobson
2018-02-15 12:00 ` Eli Zaretskii
0 siblings, 1 reply; 28+ messages in thread
From: 積丹尼 Dan Jacobson @ 2018-02-15 6:24 UTC (permalink / raw)
To: 30462
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
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-18 0:14 ` Richard Stallman
0 siblings, 2 replies; 28+ messages in thread
From: Eli Zaretskii @ 2018-02-15 12:00 UTC (permalink / raw)
To: 30462, jidanni
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-15 12:00 ` Eli Zaretskii
@ 2018-02-15 12:56 ` 積丹尼 Dan Jacobson
2018-02-15 16:56 ` Eli Zaretskii
2018-02-18 0:14 ` Richard Stallman
1 sibling, 1 reply; 28+ messages in thread
From: 積丹尼 Dan Jacobson @ 2018-02-15 12:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462
>>>>> "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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
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
0 siblings, 2 replies; 28+ messages in thread
From: Eli Zaretskii @ 2018-02-15 16:56 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: 30462
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-15 16:56 ` Eli Zaretskii
@ 2018-02-16 0:22 ` 積丹尼 Dan Jacobson
2018-02-16 10:15 ` Dmitry Gutov
1 sibling, 0 replies; 28+ messages in thread
From: 積丹尼 Dan Jacobson @ 2018-02-16 0:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462
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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
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
1 sibling, 1 reply; 28+ messages in thread
From: Dmitry Gutov @ 2018-02-16 10:15 UTC (permalink / raw)
To: Eli Zaretskii, 積丹尼 Dan Jacobson; +Cc: 30462
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
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
0 siblings, 2 replies; 28+ messages in thread
From: Eli Zaretskii @ 2018-02-16 10:55 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 30462, jidanni
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-16 10:55 ` Eli Zaretskii
@ 2018-02-16 11:03 ` 積丹尼 Dan Jacobson
2018-02-16 11:36 ` Dmitry Gutov
1 sibling, 0 replies; 28+ messages in thread
From: 積丹尼 Dan Jacobson @ 2018-02-16 11:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462, Dmitry Gutov
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
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
1 sibling, 1 reply; 28+ messages in thread
From: Dmitry Gutov @ 2018-02-16 11:36 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462, jidanni
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-16 11:36 ` Dmitry Gutov
@ 2018-02-16 13:47 ` Eli Zaretskii
2018-02-16 14:18 ` Eli Zaretskii
2018-02-20 0:51 ` Dmitry Gutov
0 siblings, 2 replies; 28+ messages in thread
From: Eli Zaretskii @ 2018-02-16 13:47 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 30462, jidanni
> 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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-16 13:47 ` Eli Zaretskii
@ 2018-02-16 14:18 ` Eli Zaretskii
2018-02-16 14:33 ` Eli Zaretskii
2018-02-20 0:28 ` Dmitry Gutov
2018-02-20 0:51 ` Dmitry Gutov
1 sibling, 2 replies; 28+ messages in thread
From: Eli Zaretskii @ 2018-02-16 14:18 UTC (permalink / raw)
To: jidanni; +Cc: 30462, dgutov
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-16 14:18 ` Eli Zaretskii
@ 2018-02-16 14:33 ` Eli Zaretskii
2018-02-17 0:58 ` 積丹尼 Dan Jacobson
2018-02-20 0:28 ` Dmitry Gutov
1 sibling, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2018-02-16 14:33 UTC (permalink / raw)
To: jidanni; +Cc: 30462, dgutov
> 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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-16 14:33 ` Eli Zaretskii
@ 2018-02-17 0:58 ` 積丹尼 Dan Jacobson
2018-02-17 7:47 ` Eli Zaretskii
0 siblings, 1 reply; 28+ messages in thread
From: 積丹尼 Dan Jacobson @ 2018-02-17 0:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462, dgutov
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-17 0:58 ` 積丹尼 Dan Jacobson
@ 2018-02-17 7:47 ` Eli Zaretskii
2018-02-17 11:43 ` 積丹尼 Dan Jacobson
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
From: Eli Zaretskii @ 2018-02-17 7:47 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: 30462, dgutov
> 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?
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
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
2 siblings, 0 replies; 28+ messages in thread
From: 積丹尼 Dan Jacobson @ 2018-02-17 11:43 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462, dgutov
>>>>> "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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
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
2 siblings, 0 replies; 28+ messages in thread
From: 積丹尼 Dan Jacobson @ 2018-02-17 14:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462, dgutov
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 >
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
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
2 siblings, 1 reply; 28+ messages in thread
From: 積丹尼 Dan Jacobson @ 2018-02-17 15:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462, dgutov
[-- 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
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
0 siblings, 2 replies; 28+ messages in thread
From: Eli Zaretskii @ 2018-02-17 16:09 UTC (permalink / raw)
To: 積丹尼 Dan Jacobson; +Cc: 30462, dgutov
> 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)
^ permalink raw reply related [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-17 16:09 ` Eli Zaretskii
@ 2018-02-17 23:37 ` 積丹尼 Dan Jacobson
2018-02-20 0:24 ` Dmitry Gutov
1 sibling, 0 replies; 28+ messages in thread
From: 積丹尼 Dan Jacobson @ 2018-02-17 23:37 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462, dgutov
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...
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-15 12:00 ` Eli Zaretskii
2018-02-15 12:56 ` 積丹尼 Dan Jacobson
@ 2018-02-18 0:14 ` Richard Stallman
1 sibling, 0 replies; 28+ messages in thread
From: Richard Stallman @ 2018-02-18 0:14 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462, jidanni
[[[ 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
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
1 sibling, 1 reply; 28+ messages in thread
From: Dmitry Gutov @ 2018-02-20 0:24 UTC (permalink / raw)
To: Eli Zaretskii, 積丹尼 Dan Jacobson; +Cc: 30462
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!
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-16 14:18 ` Eli Zaretskii
2018-02-16 14:33 ` Eli Zaretskii
@ 2018-02-20 0:28 ` Dmitry Gutov
2018-02-20 4:24 ` Eli Zaretskii
1 sibling, 1 reply; 28+ messages in thread
From: Dmitry Gutov @ 2018-02-20 0:28 UTC (permalink / raw)
To: Eli Zaretskii, jidanni; +Cc: 30462
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-16 13:47 ` Eli Zaretskii
2018-02-16 14:18 ` Eli Zaretskii
@ 2018-02-20 0:51 ` Dmitry Gutov
1 sibling, 0 replies; 28+ messages in thread
From: Dmitry Gutov @ 2018-02-20 0:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462, jidanni
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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-20 0:24 ` Dmitry Gutov
@ 2018-02-20 4:08 ` Eli Zaretskii
2018-03-03 10:49 ` Eli Zaretskii
0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2018-02-20 4:08 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 30462, jidanni
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-20 0:28 ` Dmitry Gutov
@ 2018-02-20 4:24 ` Eli Zaretskii
2018-02-20 11:38 ` Dmitry Gutov
0 siblings, 1 reply; 28+ messages in thread
From: Eli Zaretskii @ 2018-02-20 4:24 UTC (permalink / raw)
To: Dmitry Gutov; +Cc: 30462, jidanni
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-20 4:24 ` Eli Zaretskii
@ 2018-02-20 11:38 ` Dmitry Gutov
2018-02-20 17:57 ` 積丹尼 Dan Jacobson
0 siblings, 1 reply; 28+ messages in thread
From: Dmitry Gutov @ 2018-02-20 11:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 30462, jidanni
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!
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-20 11:38 ` Dmitry Gutov
@ 2018-02-20 17:57 ` 積丹尼 Dan Jacobson
0 siblings, 0 replies; 28+ messages in thread
From: 積丹尼 Dan Jacobson @ 2018-02-20 17:57 UTC (permalink / raw)
To: eliz; +Cc: 30462, Dmitry Gutov
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
^ permalink raw reply [flat|nested] 28+ messages in thread
* bug#30462: flyspell-auto-correct-word 'corrects' more than the current word
2018-02-20 4:08 ` Eli Zaretskii
@ 2018-03-03 10:49 ` Eli Zaretskii
0 siblings, 0 replies; 28+ messages in thread
From: Eli Zaretskii @ 2018-03-03 10:49 UTC (permalink / raw)
To: jidanni; +Cc: 30462-done, dgutov
> 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.
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2018-03-03 10:49 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2018-02-18 0:14 ` Richard Stallman
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).