bug#34019: 26.1; Changing ispell-program-name causes unwanted behavior

bug#34019: 26.1; Changing ispell-program-name causes unwanted behavior

[Philip K.]

[-- Attachment #1.1: Type: text/plain, Size: 1178 bytes --]


Hello,

I've recently updated my Debian installation from stretch (9, stable) to
buster (10, testing) and I got to install Emacs 26.1 + enchant. But
sadly the version in the Debian repository is still too old (1.6 vs
2.1). But when changing back to aspell, I was informed that aspell was
too old (0.6 vs 2.1).

It's easy to reproduce the bug, assuming one's enchant is also too
old. Simply eval

	(setq-default ispell-program-name (executable-find "enchant"))

try spell-checking any word (which should lead to an error), followed by

	(setq-default ispell-program-name (executable-find "aspell"))

or whatever one was using before. Any spell-checking should still not
work, and an error will be reported no matter what version of
aspell/hunspell/ispell one uses.

Looking through the code I noticed that the issue was simply caused by
forgetting to reset the variable `ispell-really-enchant`, thus resetting
it fixes the issue.

I hope I haven't messed something up in the process, since this is the
first time I'm sending a patch. If that's not the case, please tell me
and I'll be eager to fix any issue (related to this bug).

	Sincerely,
	Philip K.
    https://zge.us.to


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-re-initialize-ispell-really-enchant-properly.patch --]
[-- Type: text/x-diff, Size: 885 bytes --]

From 25e0c36e60ee9737e92994684887fe9a4062b0cc Mon Sep 17 00:00:00 2001
From: Philip K <philip@warpmail.net>
Date: Wed, 9 Jan 2019 00:37:48 +0100
Subject: [PATCH] (re-)initialize ispell-really-enchant properly
To: bug-gnu-emacs@gnu.org

* lisp/textmodes/ispell.el: adding missing variable that should have
  been reset
---
 lisp/textmodes/ispell.el | 1 +
 1 file changed, 1 insertion(+)

diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el
index 22047598b2..0b07254af4 100644
--- a/lisp/textmodes/ispell.el
+++ b/lisp/textmodes/ispell.el
@@ -726,7 +726,7 @@ ispell-check-version
 	;; Make sure these variables are (re-)initialized to the default value
 	(setq ispell-really-aspell nil
               ispell-really-hunspell nil
+              ispell-really-enchant nil
 	      ispell-encoding8-command nil)
 
 	(goto-char (point-min))
---
2.20.1


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#34019: 26.1; Changing ispell-program-name causes unwanted behavior

[Eli Zaretskii]

> From: philip@warpmail.net (Philip K.)
> Date: Wed, 09 Jan 2019 01:01:18 +0100
> 
> I've recently updated my Debian installation from stretch (9, stable) to
> buster (10, testing) and I got to install Emacs 26.1 + enchant. But
> sadly the version in the Debian repository is still too old (1.6 vs
> 2.1). But when changing back to aspell, I was informed that aspell was
> too old (0.6 vs 2.1).
> 
> It's easy to reproduce the bug, assuming one's enchant is also too
> old. Simply eval
> 
> 	(setq-default ispell-program-name (executable-find "enchant"))
> 
> try spell-checking any word (which should lead to an error), followed by
> 
> 	(setq-default ispell-program-name (executable-find "aspell"))
> 
> or whatever one was using before. Any spell-checking should still not
> work, and an error will be reported no matter what version of
> aspell/hunspell/ispell one uses.
> 
> Looking through the code I noticed that the issue was simply caused by
> forgetting to reset the variable `ispell-really-enchant`, thus resetting
> it fixes the issue.

Thanks, pushed to the emacs-26 branch, and will appear in Emacs 26.2.

> I hope I haven't messed something up in the process, since this is the
> first time I'm sending a patch. If that's not the case, please tell me
> and I'll be eager to fix any issue (related to this bug).

The commit log message should state the function in which the change
was made.  See the commit I actually made.  Otherwise, the patch was
OK, but for some reason it "git am" didn't apply it; perhaps because
you seem to have customized the number of context lines?