bug#14192: 24.3.50; recursive edit while running ispell not working usefully

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Michael Heerdegen]

Hi,

I think the most common use of entering a recursive edit in an ispell
session (C-r) would be to modify the checked buffer - especially, to
substitute the currently checked word with some other text.  But
whenever I exit the recursive edit (C-M-c), the deleted text reappears
and is highlighted again as unknown by ispell.  I see this in emacs -Q,
e.g. after M-x ispell-buffer in *scratch*.

If this most simple case - replacing the current word - is not working,
we shouldn't IMHO advertise C-r in `ispell-help' etc.

(Had raised this issue in emacs.devel before, but had gotten no answer.)


Thanks,

Michael.




In GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2)
 of 2013-04-10 on dex, modified by Debian
 (emacs-snapshot package, version 2:20130410-1)
Windowing system distributor `The X.Org Foundation', version 11.0.11204000
System Description:	Debian GNU/Linux 7.0 (wheezy)

Configured using:
 `configure --build x86_64-linux-gnu --host x86_64-linux-gnu
 --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var --infodir=/usr/share/info --mandir=/usr/share/man
 --with-pop=yes
 --enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.3.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3.50/site-lisp:/usr/share/emacs/site-lisp
 --without-compress-info --with-crt-dir=/usr/lib/x86_64-linux-gnu/
 --with-x=yes --with-x-toolkit=gtk3 --with-imagemagick=yes
 CFLAGS='-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'
 CPPFLAGS='-D_FORTIFY_SOURCE=2' LDFLAGS='-g -Wl,--as-needed
 -znocombreloc''

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LC_TIME: C
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Hi,
>
> I think the most common use of entering a recursive edit in an ispell
> session (C-r) would be to modify the checked buffer - especially, to
> substitute the currently checked word with some other text.  But
> whenever I exit the recursive edit (C-M-c), the deleted text reappears
> and is highlighted again as unknown by ispell.  I see this in emacs -Q,
> e.g. after M-x ispell-buffer in *scratch*.

Some comments after debugging a bit:

`ispell-process-line' sets the variable `replace' to the result of
`ispell-command-loop'.  `ispell-command-loop', however, returns the
_old_ word.  Why?

In `ispell-command-loop', search for the cond-clause of (= char ?\C-r).
The clause returns (list word nil), where `word' is the (old, unchanged)
current word.  There is this comment at that position:

; recheck starting at this word.

If I change the clause so that it just returns nil, the bug is fixed,
but the replaced text is not being checked again (I could live with
that).

As a fix, we could try to return something reflecting the change that
was maybe made in the buffer.


Regards,

Michael.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Stefan Kangas]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> Hi,
>>
>> I think the most common use of entering a recursive edit in an ispell
>> session (C-r) would be to modify the checked buffer - especially, to
>> substitute the currently checked word with some other text.  But
>> whenever I exit the recursive edit (C-M-c), the deleted text reappears
>> and is highlighted again as unknown by ispell.  I see this in emacs -Q,
>> e.g. after M-x ispell-buffer in *scratch*.
>
> Some comments after debugging a bit:
>
> `ispell-process-line' sets the variable `replace' to the result of
> `ispell-command-loop'.  `ispell-command-loop', however, returns the
> _old_ word.  Why?
>
> In `ispell-command-loop', search for the cond-clause of (= char ?\C-r).
> The clause returns (list word nil), where `word' is the (old, unchanged)
> current word.  There is this comment at that position:
>
> ; recheck starting at this word.
>
> If I change the clause so that it just returns nil, the bug is fixed,
> but the replaced text is not being checked again (I could live with
> that).
>
> As a fix, we could try to return something reflecting the change that
> was maybe made in the buffer.

That was 10 years ago, so I'm reaching out to see if this is still
an issue on a modern version of Emacs.

If I don't hear back from you within a couple of months, Ill just assume
that this has been fixed and close this bug.

Thanks in advance.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> That was 10 years ago, so I'm reaching out to see if this is still
> an issue on a modern version of Emacs.

AFAIK, nothing has changed in the behavior since then.

I guess the authors did not intend the recursive edit to be used to
change the buffer text.
But if somebody uses it to change the buffer text, Emacs will happily
mess it up.

> If I don't hear back from you within a couple of months, Ill just assume
> that this has been fixed and close this bug.

I hope this is not your standard reply.  I mean, ten years, I could have
died in the meantime, which would not mean that the bug has magically
disappeared.  I hope you send this kind of text only to people you know
that are still using Emacs regularly.  Because, if some user asks a
question, gets no answer, then makes a bug report, and is ignored for
ten years, it is very unfriendly to request anything at all.  I
know about the situation of our bug collection, but this is not
expedient.  You can't expect anyone to even still use Emacs after
a whole decade.


Michael.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Eli Zaretskii]

> Cc: 14192@debbugs.gnu.org
> Date: Thu, 11 Jan 2024 04:13:50 +0100
> From:  Michael Heerdegen via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > If I don't hear back from you within a couple of months, Ill just assume
> > that this has been fixed and close this bug.
> 
> I hope this is not your standard reply.  I mean, ten years, I could have
> died in the meantime, which would not mean that the bug has magically
> disappeared.  I hope you send this kind of text only to people you know
> that are still using Emacs regularly.  Because, if some user asks a
> question, gets no answer, then makes a bug report, and is ignored for
> ten years, it is very unfriendly to request anything at all.  I
> know about the situation of our bug collection, but this is not
> expedient.  You can't expect anyone to even still use Emacs after
> a whole decade.

He said "if I don't hear from you".  If there's no answer and no new
information, leaving bugs open just accumulates bugs that are not (and
cannot be) worked on.  So we made a decision to close such bugs.  If
the issue still exists and affects someone, those persons will
probably report it at some point with enough information to allow
investigating and fixing the problem.

I don't see anything wrong with this policy.  We do know from bitter
experience the downsides of not closing such bugs -- gobs of open bugs
that no one looks at.  That is worse, IMNSHO.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Stefan Kangas]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> That was 10 years ago, so I'm reaching out to see if this is still
>> an issue on a modern version of Emacs.
>
> AFAIK, nothing has changed in the behavior since then.
> I guess the authors did not intend the recursive edit to be used to
> change the buffer text.
> But if somebody uses it to change the buffer text, Emacs will happily
> mess it up.

OK, thanks.

>> If I don't hear back from you within a couple of months, Ill just assume
>> that this has been fixed and close this bug.
>
> I hope this is not your standard reply.  I mean, ten years, I could have
> died in the meantime, which would not mean that the bug has magically
> disappeared.  I hope you send this kind of text only to people you know
> that are still using Emacs regularly.  Because, if some user asks a
> question, gets no answer, then makes a bug report, and is ignored for
> ten years, it is very unfriendly to request anything at all.  I
> know about the situation of our bug collection, but this is not
> expedient.  You can't expect anyone to even still use Emacs after
> a whole decade.

Yes, this is my standard reply, and yes, if the bug reporter stops
responding, we sometimes just close the bug outright.

I'm not unsympathetic to your position, but please understand that we
have a very limited amount of resources given the tremendous stream of
incoming bugs and improvements that we have to manage.

If we don't sometimes do things summarily, maintaining Emacs will
quickly become an impossible task.  The only alternative I see is that
we simply stop caring about the number of open bugs in the bug tracker,
and then in another 5-10 years or so we nuke it from orbit and start a
new one.  That would lose even more information, but it's not like the
prospect does not sometimes sound pretty appealing.

So do tell us if we make mistakes, but please be patient with us if we
aren't always as polite or diligent as we are on our best days.

Or, even better, volunteer more time to help us fix the bugs.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> He said "if I don't hear from you".  If there's no answer and no new
> information, leaving bugs open just accumulates bugs that are not (and
> cannot be) worked on.

The "cannot be" part is not true in this case.  I provided an easy
recipe, the problem is reproducible in a few seconds.

> So we made a decision to close such bugs.  If the issue still exists
> and affects someone, those persons will probably report it at some
> point with enough information to allow investigating and fixing the
> problem.

And I provided a lot of information, and even an analysis.

> I don't see anything wrong with this policy.

This policy is good, but not appropriate in this case.

> We do know from bitter experience the downsides of not closing such
> bugs -- gobs of open bugs that no one looks at.  That is worse,
> IMNSHO.

That's a big problem, I know about it.  I remember Lars' statistics.

However the other side is also important.  I remember a discussion a
year or so ago, when somebody mentioned something is not working, and a
few people added that it doesn't work for them as well.  Then you
wondered why nobody had created a bug report..

It is important to give the people reporting bugs a good feeling.  The
feedback they get after such a long time should not sound that negative.
Ignored a report for such a long time is not nice, and even if it's not
our fault, we could say that we are sorry about that.  Choosing a more
positive will also raise the chance of a reply.  If this is a standard
text, it might be worth the time to improve it.

Michael.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> So do tell us if we make mistakes, but please be patient with us if we
> aren't always as polite or diligent as we are on our best days.

All good - see my reply to Eli.  But please try to be as polite as
possible, given the mountain of bugs in front of you.  I don't care
personally, but it's good to not leave a bad impression to others.

But maybe we can quickly handle this report?  What's your opinion about
the behavior of Emacs?

AFAIR after I had made the report I had been told that for replacing
words I should use r or R instead of C-r aka recursive-edit (have a
better memory than I thought I would have...maybe it had been Eli).  And
that the r-e is more for looking up words in a dictionary or such
things, not to make buffer changes.  Nonetheless do I still dislike the
behavior of C-r.  Does it make sense to you, does it have advantages I
don't see?

TIA,

Michael.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Eli Zaretskii]

> Cc: 14192@debbugs.gnu.org
> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 11 Jan 2024 12:35:11 -0800
> 
> Michael Heerdegen <michael_heerdegen@web.de> writes:
> 
> >> That was 10 years ago, so I'm reaching out to see if this is still
> >> an issue on a modern version of Emacs.
> >
> > AFAIK, nothing has changed in the behavior since then.
> > I guess the authors did not intend the recursive edit to be used to
> > change the buffer text.
> > But if somebody uses it to change the buffer text, Emacs will happily
> > mess it up.
> 
> OK, thanks.

FTR: C-r indeed was not meant to be used to modify the misspelled
word.  ispell.el has 'r' and 'R' commands for that.  C-r is for
consulting the rest of the text, without modifying it and without
disrupting the spelling session.  An alternative is to type 'X', make
any modifications you want, and then resume spelling with "C-u M-$".

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Stefan Kangas]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> It is important to give the people reporting bugs a good feeling.  The
> feedback they get after such a long time should not sound that negative.
> Ignored a report for such a long time is not nice, and even if it's not
> our fault, we could say that we are sorry about that.  Choosing a more
> positive will also raise the chance of a reply.  If this is a standard
> text, it might be worth the time to improve it.

Thanks for raising your concerns.  I think you are broadly correct, so
I'll try harder to be positive when asking for more feedback.

I'll consider adjusting my standard texts, too.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Stefan Kangas <stefankangas@gmail.com> writes:

> Thanks for raising your concerns.  I think you are broadly correct, so
> I'll try harder to be positive when asking for more feedback.
>
> I'll consider adjusting my standard texts, too.

Thanks for considering my suggestion.

Instead of staring with "This was N years ago"  we could say something
like "we are sorry that N years passed without any developer having
investigating this problem.  Could you please help us and check if the
bug is still reproducible for you"?  - Something like this maybe.

Michael.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> FTR: C-r indeed was not meant to be used to modify the misspelled
> word.  ispell.el has 'r' and 'R' commands for that.  C-r is for
> consulting the rest of the text, without modifying it and without
> disrupting the spelling session.  An alternative is to type 'X', make
> any modifications you want, and then resume spelling with "C-u M-$".

Thanks - especially for your concretizations of the spell checking
related parts in the user manual.

I find it an a bit obscure design that there is C-r that reverses edits,
then X, which allows to resume the session, and C-g, which doesn't allow
resuming.  Maybe less commands would suffice.  But I don't use ispell
often, I can't really tell whether the interface is intuitive, and
nobody else seems to be interested in this topic.

So, if we don't get any other replies until some more time has passed,
I'm ok with closing this one.


Thanks,

Michael.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  14192@debbugs.gnu.org
> Date: Sun, 14 Jan 2024 02:25:20 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > FTR: C-r indeed was not meant to be used to modify the misspelled
> > word.  ispell.el has 'r' and 'R' commands for that.  C-r is for
> > consulting the rest of the text, without modifying it and without
> > disrupting the spelling session.  An alternative is to type 'X', make
> > any modifications you want, and then resume spelling with "C-u M-$".
> 
> Thanks - especially for your concretizations of the spell checking
> related parts in the user manual.
> 
> I find it an a bit obscure design that there is C-r that reverses edits,
> then X, which allows to resume the session, and C-g, which doesn't allow
> resuming.  Maybe less commands would suffice.  But I don't use ispell
> often, I can't really tell whether the interface is intuitive, and
> nobody else seems to be interested in this topic.

I'm not opposed to patches to maybe make the C-r scenario less
surprising.  But in general, C-r is an obscure command in this case;
it isn't an accident that it was not even documented in the user
manual until recently.  The alternatives described above are IMO
better.

> So, if we don't get any other replies until some more time has passed,
> I'm ok with closing this one.

Will do in a week or two.

Thanks.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Michael Heerdegen via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

> I'm not opposed to patches to maybe make the C-r scenario less
> surprising.  But in general, C-r is an obscure command in this case;
> it isn't an accident that it was not even documented in the user
> manual until recently.  The alternatives described above are IMO
> better.

I've thought a while about it, also about improvements.  But I too came
to the conclusion that the general approach of C-r is not optimal and we
already have better alternatives, so I think telling the user to avoid
the command and keep it for backward compatibility is the final solution
for me.

Michael.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: stefankangas@gmail.com,  14192@debbugs.gnu.org
> Date: Tue, 16 Jan 2024 20:23:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'm not opposed to patches to maybe make the C-r scenario less
> > surprising.  But in general, C-r is an obscure command in this case;
> > it isn't an accident that it was not even documented in the user
> > manual until recently.  The alternatives described above are IMO
> > better.
> 
> I've thought a while about it, also about improvements.  But I too came
> to the conclusion that the general approach of C-r is not optimal and we
> already have better alternatives, so I think telling the user to avoid
> the command and keep it for backward compatibility is the final solution
> for me.

Thanks.

bug#14192: 24.3.50; recursive edit while running ispell not working usefully

[Eli Zaretskii]

> Cc: 14192@debbugs.gnu.org, stefankangas@gmail.com
> Date: Sun, 14 Jan 2024 08:29:33 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Michael Heerdegen <michael_heerdegen@web.de>
> > Cc: Stefan Kangas <stefankangas@gmail.com>,  14192@debbugs.gnu.org
> > Date: Sun, 14 Jan 2024 02:25:20 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > FTR: C-r indeed was not meant to be used to modify the misspelled
> > > word.  ispell.el has 'r' and 'R' commands for that.  C-r is for
> > > consulting the rest of the text, without modifying it and without
> > > disrupting the spelling session.  An alternative is to type 'X', make
> > > any modifications you want, and then resume spelling with "C-u M-$".
> > 
> > Thanks - especially for your concretizations of the spell checking
> > related parts in the user manual.
> > 
> > I find it an a bit obscure design that there is C-r that reverses edits,
> > then X, which allows to resume the session, and C-g, which doesn't allow
> > resuming.  Maybe less commands would suffice.  But I don't use ispell
> > often, I can't really tell whether the interface is intuitive, and
> > nobody else seems to be interested in this topic.
> 
> I'm not opposed to patches to maybe make the C-r scenario less
> surprising.  But in general, C-r is an obscure command in this case;
> it isn't an accident that it was not even documented in the user
> manual until recently.  The alternatives described above are IMO
> better.
> 
> > So, if we don't get any other replies until some more time has passed,
> > I'm ok with closing this one.
> 
> Will do in a week or two.

Done.