GNU bug report logs - #42248
27.0.91; With enchant-2.2.8 from Guix, Flyspell errors out or gives lots of false positives

Previous Next

Full log

View this message in rfc822 format

From: Jorge P. de Morais Neto <jorge+list <at> disroot.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 42248 <at> debbugs.gnu.org, stefan <at> marxist.se
Subject: bug#42248: 27.0.91; With enchant-2.2.8 from Guix, Flyspell errors out or gives lots of false positives
Date: Sun, 30 Aug 2020 15:51:42 -0300

Em [2020-08-24 seg 17:42:53+0300], Eli Zaretskii escreveu:
> Maybe the dictionary you are using doesn't support the apostrophe?

Yes, with your help, I found out that Debian's hunspell-en-us package is
missing the apostrophe in WORDCHARS value in
`/usr/share/hunspell/en_US.aff'.  I have worked around the problem by:
1. Create `~/.config/enchant/hunspell' directory and `cd' to it
2. Symlink `/usr/share/hunspell/en_US.dic' to `./en_US.dic'
3. Copy `/usr/share/hunspell/en_US.aff' to `./en_US.aff'
4. Edit `./en_US.aff' and fix WORDCHARS.

This solves the Emacs contraction problem and doesn't seem to harm other
enchant consumers like LibreOffice and Gedit.  I think I should report
this to the dictionary developers.  And where did you get your en_US
dictionary from?  The en_US hunspell dictionary is wrong both in Debian
buster and Guix.

And what should we do about ispell-dictionary-alist still including "-B"
among ISPELL-ARGS for many of its entries?  This causes an error if the
user chooses one of those dictionaries, such as "american".

> I don't think I understand the proposed changes -- can you tell in
> more detail why they are needed?

The revised patch:
--8<---------------cut here---------------start------------->8---
--- 27.1/ispell.el	2020-08-30 12:45:49.113459675 -0300
+++ lisp/ispell.el	2020-08-30 08:58:57.182813606 -0300
@@ -1237,11 +1237,12 @@
   "Find Enchant's dictionaries, and record in `ispell-enchant-dictionary-alist'."
   (let* ((dictionaries
 	  (split-string
-	   (ispell--call-enchant-lsmod "-list-dicts" (buffer-string)) " ([^)]+)\n"))
+	   (ispell--call-enchant-lsmod "-list-dicts")
+	   " ([^)]+)\n" t))
          (found
           (mapcar #'(lambda (lang)
                       `(,lang "[[:alpha:]]" "[^[:alpha:]]"
-                              ,(ispell--get-extra-word-characters) t nil nil utf-8))
+                              ,(ispell--get-extra-word-characters lang) t nil nil utf-8))
                   dictionaries)))
     ;; Merge into FOUND any elements from the standard ispell-dictionary-base-alist
     ;; which have no element in FOUND at all.
--8<---------------cut here---------------end--------------->8---

The patch removes the extraneous `(buffer-string)' argument to
`ispell--call-enchant-lsmod'.  That argument was passed as the final
argument to `enchant-lsmod-2', which is wrong.  The command we want to
invoke is only `enchant-lsmod-2 -list-dicts'---that is the command to
list Enchant dictionaries according to the enchant-lsmod-2 manpage.  And
it actually works in practice, unlike the former invocation which causes
an error.

The patch also passes t as the OMIT-NULLS argument of `split-string'.
This correctly avoids a final "" string in the return value of
`split-string', because the output of `enchant-lsmod-2 -list-dicts' ends
in a separator.

Finally, the patch passes `lang' to `ispell--get-extra-word-characters',
because the whole point of the invocation is to get the
extra word characters for the language under examination; the former
code always returned the extra word characters for the default language.

The current source code is visibly broken.  And in fact, without my
patch, when you invoke `emacs -q', evaluate (setq ispell-program-name
"enchant-2"), open the original ispell.el.gz, invoke M-x eval-buffer and
then M-x ispell-change-dictionary, you can see the error in the list of
languages.

On the other hand, when you invoke `emacs -q', evaluate
(setq ispell-program-name "enchant-2") and then
M-x ispell-change-dictionary, there is no error!  This makes me suspect
that, somehow, `ispell.elc' does not correspond to `ispell.el.gz'.  That
is a weird idea, but is the only explanation I can think of.  This
occurs on the emacs-27 branch, commit 29708cbde7.

Best regards

-- 
- <https://jorgemorais.gitlab.io/justice-for-rms/>
- I am Brazilian.  I hope my English is correct and I welcome feedback.
- Free Software Supporter: <https://www.fsf.org/free-software-supporter>
- If an email of mine arrives at your spam box, please notify me.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.