GNU bug report logs -
#14192
24.3.50; recursive edit while running ispell not working usefully
Previous Next
Reported by: michael_heerdegen <at> web.de
Date: Fri, 12 Apr 2013 15:06:01 UTC
Severity: normal
Tags: moreinfo
Found in version 24.3.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sat, 27 Jan 2024 11:09:52 +0200
with message-id <86zfwr87mn.fsf <at> gnu.org>
and subject line Re: bug#14192: 24.3.50; recursive edit while running ispell not working usefully
has caused the debbugs.gnu.org bug report #14192,
regarding 24.3.50; recursive edit while running ispell not working usefully
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
14192: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=14192
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
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
[Message part 3 (message/rfc822, inline)]
> Cc: 14192 <at> debbugs.gnu.org, stefankangas <at> gmail.com
> Date: Sun, 14 Jan 2024 08:29:33 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> > From: Michael Heerdegen <michael_heerdegen <at> web.de>
> > Cc: Stefan Kangas <stefankangas <at> gmail.com>, 14192 <at> debbugs.gnu.org
> > Date: Sun, 14 Jan 2024 02:25:20 +0100
> >
> > Eli Zaretskii <eliz <at> 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.
This bug report was last modified 1 year and 172 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.