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: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jorge+list <at> disroot.org, 42248 <at> debbugs.gnu.org
Subject: bug#42248: 27.0.91; With enchant-2.2.8 from Guix, Flyspell errors out or gives lots of false positives
Date: Thu, 27 Aug 2020 12:05:04 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > However, both ispell-buffer and Flyspell still misreport "doesn't".
>>
>> I am using Hunspell and it misrepresents "doesn't" as a typo here, too.
>
> It isn't the Hunspell issue, it's an issue with the dictionary.  What
> does your en_US.aff file says in the WORDCHARS line(s)?  See the
> function ispell-parse-hunspell-affix-file which parses the Hunspell
> aff files.

WORDCHARS 0123456789

I also found this Debian bug report (with no reply since 2008):

    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=491638

So I guess this is just broken on Debian GNU/Linux.

> On my system, there's no issue with "don't" (and the apostrophe in
> general).
>
> Eventually, the dictionary's entry in the ispell.el's DB is what
> matters.  What do you have there?

Which variable would be of interest?  In
`ispell-hunspell-dictionary-alist' I have the following entry for
"en_US":

("en_US" . #1=("[[:alpha:]]" "[^[:alpha:]]" "[0-9]" t
                ("-d" "en_US")
                nil utf-8))

Is there anything we could do to work around this situation on our end?
(It seems like LibreOffice doesn't have this problem.)

PS. I also saw this unrelated bug report which refers to our workaround
    for "hunspell -D" in hunspell 1.7.0:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659281

Previous Next

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