Discussion:
bug#19229: A workaround for hunspell
(too old to reply)
Chris Zheng
2014-11-30 19:50:50 UTC
Permalink
Hi Alexander,
I think I have wasted more time than you. :( I have a way to
workaround this problem. See the below diff. I don't know whether
this affect *nix users, so it just stays in my init files.

*** a Mon Dec 1 03:40:31 2014
--- b Mon Dec 1 03:40:31 2014
***************
*** 27,33 ****
(error "ispell-fhd: Default dict already defined as %s. Not using %s.\n"
hunspell-default-dict dict)
(setq affix-file dict)
! (setq hunspell-default-dict (list basename affix-file)))
(if (and (not (assoc basename ispell-hunspell-dict-paths-alist))
(file-exists-p affix-file))
;; Entry has an associated .aff file and no previous value.
--- 27,35 ----
(error "ispell-fhd: Default dict already defined as %s. Not using %s.\n"
hunspell-default-dict dict)
(setq affix-file dict)
! (setq hunspell-default-dict (list basename affix-file))
! (add-to-list 'ispell-hunspell-dict-paths-alist
! (list basename affix-file)))
(if (and (not (assoc basename ispell-hunspell-dict-paths-alist))
(file-exists-p affix-file))
;; Entry has an associated .aff file and no previous value.
Eli Zaretskii
2014-11-30 21:15:23 UTC
Permalink
Date: Sun, 30 Nov 2014 19:25:45 +0100
Wasted the whole day on trying to make Hunspell work with Emacs on Windows and
still out of luck.
Works for me out of the box, FWIW.
(setq ispell-program-name (executable-find "hunspell"))
(setq ispell-dictionary "en_US")
(require 'ispell)
This is the most basic configuration that should definitely work.
$ hunspell -D
.;C:/Tools/x64/MSYS2/mingw64/bin/;C:/Tools/x64/MSYS2/mingw64/share/hunspell;C:/Tools/x64/MSYS2/mingw64/share/myspell;C:/Tools/x64/MSYS2/mingw64/share/myspell/dicts;%USERPROFILE%\/Application
Data/OpenOffice.org
2/user/wordbook;C:/Tools/x64/MSYS2/mingw64/share/hunspell;C:/Tools/x64/MSYS2/mingw64/share/myspell;C:/Tools/x64/MSYS2/mingw64/share/myspell/dicts
^^^^^^^^^^^^^^^^^^^^^^
Why is this list empty?
C:/Tools/x64/MSYS2/mingw64/share/hunspell/en_US.aff
C:/Tools/x64/MSYS2/mingw64/share/hunspell/en_US.dic
Hunspell 1.3.3
ispell-phaf: No matching entry for ...
and it's no surprise because `ispell-hunspell-dict-paths-alist' is `nil'. Why?
Maybe your Hunspell port is broken? Can you try this one:

http://sourceforge.net/projects/ezwinports/files/hunspell-1.3.2-3-w32-bin.zip/download

Here's what I get from -D with that port:

SEARCH PATH:
.;;C:\Hunspell\;D:\usr\eli\.openoffice.org\3\user\wordbook;D:\usr\bin\..\share\hunspell;C:\Program files\OpenOffice.org 2.4\share\dict\ooo\;C:\Program files\OpenOffice.org 2.3\share\dict\ooo\;C:\Program files\OpenOffice.org 2.2\share\dict\ooo\;C:\Program files\OpenOffice.org 2.1\share\dict\ooo\;C:\Program files\OpenOffice.org 2.0\share\dict\ooo\
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
D:\usr\bin\..\share\hunspell\american
D:\usr\bin\..\share\hunspell\default
D:\usr\bin\..\share\hunspell\de_AT
D:\usr\bin\..\share\hunspell\de_CH
D:\usr\bin\..\share\hunspell\de_DE
D:\usr\bin\..\share\hunspell\de_DE_frami
D:\usr\bin\..\share\hunspell\ENU
D:\usr\bin\..\share\hunspell\en_GB
D:\usr\bin\..\share\hunspell\en_MED
D:\usr\bin\..\share\hunspell\en_US
D:\usr\bin\..\share\hunspell\he_IL
D:\usr\bin\..\share\hunspell\russian
D:\usr\bin\..\share\hunspell\ru_RU
D:\usr\bin\..\share\hunspell\sv_SE
LOADED DICTIONARY:
D:\usr\bin\..\share\hunspell\default.aff
D:\usr\bin\..\share\hunspell\default.dic
Hunspell 1.3.2

and my ispell-hunspell-dict-paths-alist is definitely not empty, it is
filled by the dictionaries listed in the AVAILABLE DICTIONARIES
section.
Eli Zaretskii
2014-12-01 16:24:21 UTC
Permalink
Date: Sun, 30 Nov 2014 22:55:17 +0100
Thanks a lot for the tip.
(setq ispell-program-name (executable-find "hunspell"))
(setq ispell-local-dictionary "en_US")
(setq ispell-local-dictionary-alist '(("en_US"
"[[:alpha:]]"
"[^[:alpha:]]"
"[']"
nil
nil
nil
utf-8)))
I think you don't need most of this, see below.
Nevertheless, I can still see
ispell-phaf: No matching entry for nil
I don't see it on my system. With "emacs -Q", all I need is to
evaluate

(setq ispell-program-name (executable-find "hunspell"))

After that, "M-x ispell-buffer RET" works as expected, and I see no
error messages about ispell-phaf in *Messages*. Does that work for
you?
So it still tries to call `ispell-parse-hunspell-affix-file' with `nil' for the first time, and only then calls it with "en_US" in my case.
But your above minimal configuration is not how Hunspell should be set
up with Emacs 24.4 and later. First, it is best to set up the default
dictionary to be for the language you spellcheck the most. If that's
US English, then just copy en_US.* files to the corresponding
default.* files, and that's it.

If the default dictionary is not what you want, you should only need
this one additional line to switch globally to another one:

(ispell-change-dictionary "en_US" t)

(Of course, "en_US" can be replaced with any other language.) With
this one line in addition to setting ispell-program-name I get a
working spelling in US English, and no error messages in "emacs -Q".
Does this work for you?
Secondly, I think that relying on "hunspell -D" so stubbornly that `ispell-parse-hunspell-affix-file' blocks all further usage of ispell.el with hunspell if `ispell-hunspell-dict-paths-alist' is just dumb.
I don't think so. The code in ispell.el that queries the speller
about the available dictionaries is IMO a very useful feature because
asking the speller about dictionaries is the most reliable way of
detecting which ones are available and what languages/encodings they
support. Without that, Emacs must rely on the user to manually set up
ispell-local-dictionary-alist, which is error prone and cumbersome
(e.g., how do you tell which dictionary needs what encoding?).

With the original Ispell program, ispell-local-dictionary-alist was a
must, but modern spellers, like aspell and hunspell, can be queried
about the dictionaries, which makes your ispell-local-dictionary-alist
customization above entirely unnecessary.
Not all distributions of hunspell even supply "share/hunspell/*" stuff with them;
Then those distributions are simply broken: Hunspell isn't worth
anything without at least one dictionary. It's OK to provide
dictionaries in a separate archive, but not having them around at all
is bad news for Windows users who download Hunspell, because finding
these dictionaries and figuring out how to install the various RPMs
you find out there is not for the faint at heart.
Some users don't use dictionaries from "share/hunspell/*" because they might get either more updated dictionaries themselves and/or already have customized personal dictionaries.
If the dictionaries are installed in a location different from the
default share/hunspell/ directory, the user should set the DICPATH
environment variable to point to the directories with the
dictionaries, and "hunspell -D" will still report them. See "man
hunspell" for more details.
(let ((dictionaries-dir (expand-file-name "dictionaries"
user-emacs-directory)))
(make-directory dictionaries-dir t)
(setq ispell-local-dictionary "en_US")
(setq ispell-local-dictionary-alist '((nil
"[[:alpha:]]"
"[^[:alpha:]]"
"[']"
nil
("-d" "en_US"
"-p" dictionaries-dir)
nil
utf-8)
("en_US"
"[[:alpha:]]"
"[^[:alpha:]]"
"[']"
nil
("-d" "en_US"
"-p" dictionaries-dir)
nil
utf-8)
("german"
"[[:alpha:]]"
"[^[:alpha:]]"
"[']"
t
("-d" "de_DE_frami"
"-p" dictionaries-dir)
"~tex"
utf-8)
("russian"
"[[:alpha:]]"
"[^[:alpha:]]"
"[']"
nil
("-d" "ru_RU"
"-p" dictionaries-dir)
nil
utf-8)))))
and in this case I obviously don't care at all whether hunspell has anything in "share/hunspell/*" or not. So why would I be forcefully blocked to use it with some weird error from `ispell-parse-hunspell-affix-file'?
I don't see why you would need such an elaborate manual setup. (Btw,
the -p switch is not for telling Hunspell where to find the
dictionaries, it's for telling it where are your _personal_
dictionaries.) You are reinventing the wheel, fighting an uphill
battle against Hunspell and ispell.el while at that, and then complain
that it's hard. Just set DICPATH in the environment and be done, it's
much simpler. Play by the rules, and everything should "just work"
(barring bugs).

IOW, ispell.el's handling of Hunspell is based on the assumption that
the user has a working Hunspell installation with dictionaries that
the speller can find without any fancy command-line switches. I think
this is a sound assumption, and it does work for everyone else. It
will work for you as well, if you just install and configure Hunspell
properly, see above.

You can still tweak the installation and setup, of course -- this is
Emacs! -- but at least for your particular setup it's unneeded,
AFAICT; the defaults should work just fine.
How about redesign?
Do you still think it's needed?
Eli Zaretskii
2014-12-01 16:26:04 UTC
Permalink
Date: Mon, 01 Dec 2014 03:50:50 +0800
I think I have wasted more time than you. :( I have a way to
workaround this problem. See the below diff. I don't know whether
this affect *nix users, so it just stays in my init files.
*** a Mon Dec 1 03:40:31 2014
--- b Mon Dec 1 03:40:31 2014
***************
*** 27,33 ****
(error "ispell-fhd: Default dict already defined as %s. Not using %s.\n"
hunspell-default-dict dict)
(setq affix-file dict)
! (setq hunspell-default-dict (list basename affix-file)))
(if (and (not (assoc basename ispell-hunspell-dict-paths-alist))
(file-exists-p affix-file))
;; Entry has an associated .aff file and no previous value.
--- 27,35 ----
(error "ispell-fhd: Default dict already defined as %s. Not using %s.\n"
hunspell-default-dict dict)
(setq affix-file dict)
! (setq hunspell-default-dict (list basename affix-file))
! (add-to-list 'ispell-hunspell-dict-paths-alist
! (list basename affix-file)))
(if (and (not (assoc basename ispell-hunspell-dict-paths-alist))
(file-exists-p affix-file))
;; Entry has an associated .aff file and no previous value.
Please see my comments. If what I wrote there still doesn't work for
you, please describe the details of the failure. (Are you also using
the MSYS2 port of Hunspell 1.3.3? if so, please try the ezwinports
port instead.)
Alexander Shukaev
2014-12-01 17:15:33 UTC
Permalink
Thank you for detailed answer, Eli. I haven't tested it all yet, but I will
report as soon as I do.

Do you still think it's needed?
If it will work exactly as you say, then of course not! ;)

Regards,
Alexander
Alan Third
2015-05-20 18:53:22 UTC
Permalink
I've been fighting with hunspell on Windows too and I finally got a
solution that works for me from
http://emacs.stackexchange.com/questions/5756/call-process-and-hunspell-in-emacs-24-4.

Ultimately it's the LANG environment variable, or in the case of
Windows the lack of it. I found that with LANG set to "en_GB" I didn't
need any other configuration to get hunspell working. I didn't even
need to tell emacs to use hunspell.

Irritatingly OS X sets LANG to "en_GB.UTF-8", which seems to break
ispell too. Setting it as just plain "en_GB" fixes it there too.

It appears the new version of ispell in 24.4+ is very heavily
dependent on LANG to the extent that explicitly setting
ispell-dictionary won't over-ride it.
--
Alan Third
Eli Zaretskii
2015-05-20 19:21:51 UTC
Permalink
Date: Wed, 20 May 2015 19:53:22 +0100
Ultimately it's the LANG environment variable, or in the case of
Windows the lack of it. I found that with LANG set to "en_GB" I didn't
need any other configuration to get hunspell working. I didn't even
need to tell emacs to use hunspell.
I advise against that "solution", because this value of LANG might
confuse other Windows programs if they are invoked by Emacs, and even
Emacs itself, where its features depend on the locale. Windows short
names of locales are different from Posix names; in particular they
have 3 letters instead of 2. Most native Windows programs will not
understand the value such as "en_GB".

Instead, I suggest to copy en_GB.* dictionary files that Hunspell uses
to corresponding ENG.* files.

Alternatively, say something like this in your ~/.emacs:

(ispell-change-dictionary "en_GB" t)

which re-invokes Hunspell with the en_GB dictionary without messing
with your LANG variable.
It appears the new version of ispell in 24.4+ is very heavily
dependent on LANG to the extent that explicitly setting
ispell-dictionary won't over-ride it.
The value of LANG specifies the default dictionary to load, but that's
all.
Alan Third
2015-05-20 20:34:51 UTC
Permalink
Post by Eli Zaretskii
I advise against that "solution", because this value of LANG might
confuse other Windows programs if they are invoked by Emacs, and even
Emacs itself, where its features depend on the locale.
Seems fair.
Post by Eli Zaretskii
Instead, I suggest to copy en_GB.* dictionary files that Hunspell uses
to corresponding ENG.* files.
Doesn't work in OS X, but I'll give it a go in Windows tomorrow.

Annoyingly hunspell on it's own is perfectly capable of choosing the
right dictionary, and if I use aspell instead of hunspell I just need
to set:

(setq ispell-dictionary "en_GB")

in my init.el and it works without any further issues. On OS X at
least, I'll have to wait until tomorrow to try aspell in Windows. If I
can get it working, my memory is that it's awkward which is the reason
why I was trying hunspell. Well, that and the rumour that hunspell can
handle UTF-8 apostrophes when aspell can't.
Post by Eli Zaretskii
(ispell-change-dictionary "en_GB" t)
which re-invokes Hunspell with the en_GB dictionary without messing
with your LANG variable.
Unfortunately this doesn't work, I get our old friend:

ispell-phaf: No matching entry for nil.

And if I run it a second time I get:

(error "Undefined dictionary: en_GB")

I don't really understand why because at this stage
ispell-hunspell-dict-paths-alist is set to (on OS X, but I found the
same thing on Windows):

(("british" "/Library/Spelling/en_GB.aff")
("en_GB" "/Library/Spelling/en_GB.aff"))

so clearly the hunspell auto-configuration stuff is working, but
something somewhere isn't joining up.

I've given up on spell checking in emacs several times in the past and
this is the closest I've ever got to getting it working across all the
platforms I'm using.
--
Alan Third
Eli Zaretskii
2015-05-21 02:41:50 UTC
Permalink
Date: Wed, 20 May 2015 21:34:51 +0100
Post by Eli Zaretskii
Instead, I suggest to copy en_GB.* dictionary files that Hunspell uses
to corresponding ENG.* files.
Doesn't work in OS X, but I'll give it a go in Windows tomorrow.
OS X should support the original names, like en_GB, and it should have
its locale set to that already.
Post by Eli Zaretskii
(ispell-change-dictionary "en_GB" t)
which re-invokes Hunspell with the en_GB dictionary without messing
with your LANG variable.
ispell-phaf: No matching entry for nil.
Where did you get your Hunspell binary for Windows? The above works
for me, so I suspect your Hunspell is subtly broken.
(error "Undefined dictionary: en_GB")
Does that happen in "emacs -Q" as well? If not, have another look at
your Hunspell- and ispell-related customizations.
I've given up on spell checking in emacs several times in the past and
this is the closest I've ever got to getting it working across all the
platforms I'm using.
On Posix platforms (including OS X), the locale setting should do
that. On Windows, use one of the 2 methods I suggested, they do work
provided that Hunspell has its known bugs fixed.
Alan Third
2015-05-21 08:16:00 UTC
Permalink
Post by Eli Zaretskii
Date: Wed, 20 May 2015 21:34:51 +0100
Post by Eli Zaretskii
Instead, I suggest to copy en_GB.* dictionary files that Hunspell uses
to corresponding ENG.* files.
Doesn't work in OS X, but I'll give it a go in Windows tomorrow.
This works in windows! Once this is done I can then use
ispell-change-dictionary to change the dictionary to anything I want.
Presumably, then, the problem I'm seeing is that ispell+hunspell falls
over if the dictionary initially set by emacs doesn't exist.

Is there a way to force ispell+hunspell to use a different dictionary
from the start other than changing the LANG variable?

Thanks!
--
Alan Third
Post by Eli Zaretskii
Date: Wed, 20 May 2015 21:34:51 +0100
Post by Eli Zaretskii
Instead, I suggest to copy en_GB.* dictionary files that Hunspell uses
to corresponding ENG.* files.
Doesn't work in OS X, but I'll give it a go in Windows tomorrow.
OS X should support the original names, like en_GB, and it should have
its locale set to that already.
Post by Eli Zaretskii
(ispell-change-dictionary "en_GB" t)
which re-invokes Hunspell with the en_GB dictionary without messing
with your LANG variable.
ispell-phaf: No matching entry for nil.
Where did you get your Hunspell binary for Windows? The above works
for me, so I suspect your Hunspell is subtly broken.
(error "Undefined dictionary: en_GB")
Does that happen in "emacs -Q" as well? If not, have another look at
your Hunspell- and ispell-related customizations.
I've given up on spell checking in emacs several times in the past and
this is the closest I've ever got to getting it working across all the
platforms I'm using.
On Posix platforms (including OS X), the locale setting should do
that. On Windows, use one of the 2 methods I suggested, they do work
provided that Hunspell has its known bugs fixed.
--
Alan Third
Eli Zaretskii
2015-05-21 16:23:03 UTC
Permalink
Date: Thu, 21 May 2015 09:16:00 +0100
Post by Alan Third
Post by Eli Zaretskii
Instead, I suggest to copy en_GB.* dictionary files that Hunspell uses
to corresponding ENG.* files.
Doesn't work in OS X, but I'll give it a go in Windows tomorrow.
This works in windows! Once this is done I can then use
ispell-change-dictionary to change the dictionary to anything I want.
Presumably, then, the problem I'm seeing is that ispell+hunspell falls
over if the dictionary initially set by emacs doesn't exist.
Could be, but see below: using LANG is a fallback.
Is there a way to force ispell+hunspell to use a different dictionary
from the start other than changing the LANG variable?
There are several ways of doing that.

First, you can customize the variable ispell-dictionary to name the
dictionary (without the .aff or .dic extensions, just the stem of the
basename, as in "en_GB"). You can set this in your ~/.emacs. This
will cause ispell.el to invoke Hunspell with the appropriate -d
command-line option.

Alternatively, you can set the environment variable DICTIONARY to name
the dictionary, as in "set DICTIONARY=en_GB". This environment
variable is documented in the Hunspell man page.

If neither -d is used nor DICTIONARY variable is found in the
environment, Hunspell checks LC_ALL, LC_MESSAGES, and LANG variables,
in that order. LANG is already set by Emacs when it starts; you could
theoretically use one of the other two, but I don't recommend that,
again because they have specific meaning for locale-sensitive APIs,
and so other programs might react to them in ways you won't like.
Alan Third
2015-05-21 20:19:19 UTC
Permalink
Post by Eli Zaretskii
Date: Thu, 21 May 2015 09:16:00 +0100
This works in windows! Once this is done I can then use
ispell-change-dictionary to change the dictionary to anything I want.
Presumably, then, the problem I'm seeing is that ispell+hunspell falls
over if the dictionary initially set by emacs doesn't exist.
OK, I was completely wrong here.
Post by Eli Zaretskii
Is there a way to force ispell+hunspell to use a different dictionary
from the start other than changing the LANG variable?
There are several ways of doing that.
First, you can customize the variable ispell-dictionary to name the
dictionary (without the .aff or .dic extensions, just the stem of the
basename, as in "en_GB"). You can set this in your ~/.emacs. This
will cause ispell.el to invoke Hunspell with the appropriate -d
command-line option.
This doesn't work. I've done some digging in ispell.el and I think I
know what's going on.

The function ispell-find-hunspell-dictionaries parses the output of
`hunspell -D` looking for *hunspell's* default dictionary. If you
don't have any of the variables you mentioned set then hunspell
doesn't give a default.

Specifically, it looks for a line that ends ".aff" then uses that line
in an argument for ispell-parse-hunspell-affix-file, which fails if
it's nil, which in my case it is. Because that function errors,
ispell-find-hunspell-dictionaries stops processing and therefore never
builds ispell-hunspell-dictionary-alist, which seems to be a pretty
vital variable.

While that doesn't seem like very good behaviour to me, I don't know
if you'd classify it as a bug.
Post by Eli Zaretskii
Alternatively, you can set the environment variable DICTIONARY to name
the dictionary, as in "set DICTIONARY=en_GB". This environment
variable is documented in the Hunspell man page.
I suspect that, in the short term at least, setting this in my init.el
is the best solution. This will work transparently in both Windows and
OS X.

(There doesn't seem to be any simple way of setting environment
variables for "GUI" programs in recent versions of OS X. I have to set
PATH in my init.el too.)

Thanks!
--
Alan Third
Eli Zaretskii
2015-05-22 06:53:10 UTC
Permalink
Date: Thu, 21 May 2015 21:19:19 +0100
Post by Eli Zaretskii
Date: Thu, 21 May 2015 09:16:00 +0100
This works in windows! Once this is done I can then use
ispell-change-dictionary to change the dictionary to anything I want.
Presumably, then, the problem I'm seeing is that ispell+hunspell falls
over if the dictionary initially set by emacs doesn't exist.
OK, I was completely wrong here.
In what way?
Post by Eli Zaretskii
Is there a way to force ispell+hunspell to use a different dictionary
from the start other than changing the LANG variable?
There are several ways of doing that.
First, you can customize the variable ispell-dictionary to name the
dictionary (without the .aff or .dic extensions, just the stem of the
basename, as in "en_GB"). You can set this in your ~/.emacs. This
will cause ispell.el to invoke Hunspell with the appropriate -d
command-line option.
This doesn't work. I've done some digging in ispell.el and I think I
know what's going on.
The function ispell-find-hunspell-dictionaries parses the output of
`hunspell -D` looking for *hunspell's* default dictionary. If you
don't have any of the variables you mentioned set then hunspell
doesn't give a default.
What does your Hunspell say when you invoke it with -D? Mine says
this:

SEARCH PATH:
.;;C:\Hunspell\;D:\usr\eli\.openoffice.org\3\user\wordbook;D:\usr\bin\..\share\hunspell;C:\Program files\OpenOffice.org 2.4\share\dict\ooo\;C:\Program files\OpenOffice.org 2.3\share\dict\ooo\;C:\Program files\OpenOffice.org 2.2\share\dict\ooo\;C:\Program files\OpenOffice.org 2.1\share\dict\ooo\;C:\Program files\OpenOffice.org 2.0\share\dict\ooo\
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
D:\usr\bin\..\share\hunspell\american
D:\usr\bin\..\share\hunspell\default
D:\usr\bin\..\share\hunspell\de_AT
D:\usr\bin\..\share\hunspell\de_CH
D:\usr\bin\..\share\hunspell\de_DE
D:\usr\bin\..\share\hunspell\de_DE_frami
D:\usr\bin\..\share\hunspell\ENU
D:\usr\bin\..\share\hunspell\en_GB
D:\usr\bin\..\share\hunspell\en_MED
D:\usr\bin\..\share\hunspell\en_US
D:\usr\bin\..\share\hunspell\he_IL
D:\usr\bin\..\share\hunspell\russian
D:\usr\bin\..\share\hunspell\ru_RU
D:\usr\bin\..\share\hunspell\sv_SE
LOADED DICTIONARY:
D:\usr\bin\..\share\hunspell\default.aff
D:\usr\bin\..\share\hunspell\default.dic
Hunspell 1.3.2

Note that the default dictionary it loaded, as announced near the end.

Once again, I ask where you got your Hunspell binary. In the binary
distribution here:

http://sourceforge.net/projects/ezwinports/files/hunspell-1.3.2-3-w32-bin.zip/download

which is what I use, there's the "default" dictionary, in the form of
2 files: default.dic and default.aff. Do you have them in your
share/hunspell/ directory? If not, just copy your "usual" dictionary
files into those names (or toss your Hunspell installation and use
mine instead ;-).
Specifically, it looks for a line that ends ".aff" then uses that line
in an argument for ispell-parse-hunspell-affix-file, which fails if
it's nil, which in my case it is. Because that function errors,
ispell-find-hunspell-dictionaries stops processing and therefore never
builds ispell-hunspell-dictionary-alist, which seems to be a pretty
vital variable.
While that doesn't seem like very good behaviour to me, I don't know
if you'd classify it as a bug.
I see no bug here. It works for me. I think your Hunspell
installation is misconfigured, that's all.
Alan Third
2015-05-22 18:57:17 UTC
Permalink
Post by Eli Zaretskii
Date: Thu, 21 May 2015 21:19:19 +0100
Post by Eli Zaretskii
Date: Thu, 21 May 2015 09:16:00 +0100
This works in windows! Once this is done I can then use
ispell-change-dictionary to change the dictionary to anything I want.
Presumably, then, the problem I'm seeing is that ispell+hunspell falls
over if the dictionary initially set by emacs doesn't exist.
OK, I was completely wrong here.
In what way?
Well, it seems the above is right on Windows but wrong on OS X. On
Windows it tries to set the dictionary to "ENG", because that's what
emacs puts in LANG, but on OS X it never gets as far as setting a
dictionary because there's nothing at all in LANG and emacs doesn't
automatically set it.

What confuses this on OS X is that when you run hunspell from the
command line LANG *IS* set and so it works, but from within emacs (run
from the GUI) LANG *ISN'T* set so it fails.
Post by Eli Zaretskii
Post by Eli Zaretskii
First, you can customize the variable ispell-dictionary to name the
dictionary (without the .aff or .dic extensions, just the stem of the
basename, as in "en_GB"). You can set this in your ~/.emacs. This
will cause ispell.el to invoke Hunspell with the appropriate -d
command-line option.
This doesn't work. I've done some digging in ispell.el and I think I
know what's going on.
The function ispell-find-hunspell-dictionaries parses the output of
`hunspell -D` looking for *hunspell's* default dictionary. If you
don't have any of the variables you mentioned set then hunspell
doesn't give a default.
What does your Hunspell say when you invoke it with -D? Mine says
<snip>
Post by Eli Zaretskii
Note that the default dictionary it loaded, as announced near the end.
On Windows from within emacs:

SEARCH PATH:
.;;C:\Hunspell\;c:/users/thirda\.openoffice.org\3\user\wordbook;c:\Users\thirda\local\bin\..\share\hunspell;C:\Program
files\OpenOffice.org 2.4\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.3\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.2\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.1\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.0\share\dict\ooo\
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
c:\Users\thirda\local\bin\..\share\hunspell\default
c:\Users\thirda\local\bin\..\share\hunspell\en_GB
c:\Users\thirda\local\bin\..\share\hunspell\en_US
Can't open affix or dictionary files for dictionary named "ENG".

Creating an "ENG" dictionary fixes this.

On OS X from within emacs:

SEARCH PATH:
.::/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/Users/alan/.openoffice.org/3/user/wordbook::/Users/alan/.openoffice.org2/user/wordbook::/Users/alan/.openoffice.org2.0/user/wordbook::/Users/alan/Library/Spelling:/opt/openoffice.org/basis3.0/share/dict/ooo:/usr/lib/openoffice.org/basis3.0/share/dict/ooo:/opt/openoffice.org2.4/share/dict/ooo:/usr/lib/openoffice.org2.4/share/dict/ooo:/opt/openoffice.org2.3/share/dict/ooo:/usr/lib/openoffice.org2.3/share/dict/ooo:/opt/openoffice.org2.2/share/dict/ooo:/usr/lib/openoffice.org2.2/share/dict/ooo:/opt/openoffice.org2.1/share/dict/ooo:/usr/lib/openoffice.org2.1/share/dict/ooo:/opt/openoffice.org2.0/share/dict/ooo:/usr/lib/openoffice.org2.0/share/dict/ooo
AVAILABLE DICTIONARIES (path is not mandatory for -d option):
/Library/Spelling/en_GB
Can't open affix or dictionary files for dictionary named "default".

Creating an ENG dictionary doesn't help here because:

(getenv "LANG")

returns nil.
Post by Eli Zaretskii
Once again, I ask where you got your Hunspell binary. In the binary
http://sourceforge.net/projects/ezwinports/files/hunspell-1.3.2-3-w32-bin.zip/download
That's the one I'm using on Windows.

On OS X I'm using the one from "homebrew", which seems to be up to
date.

And I've just worked out where I need to put a default dictionary to
get it to work: /usr/share/myspell.
Post by Eli Zaretskii
Specifically, it looks for a line that ends ".aff" then uses that line
in an argument for ispell-parse-hunspell-affix-file, which fails if
it's nil, which in my case it is. Because that function errors,
ispell-find-hunspell-dictionaries stops processing and therefore never
builds ispell-hunspell-dictionary-alist, which seems to be a pretty
vital variable.
While that doesn't seem like very good behaviour to me, I don't know
if you'd classify it as a bug.
I see no bug here. It works for me. I think your Hunspell
installation is misconfigured, that's all.
That's why I wasn't sure if you'd think it was a bug. :)

I tried wrapping the call to ispell-parse-hunspell-affix-file in an if
that checks whether hunspell-default-dict is set and the error
messages went away. Then I could use ispell-dictionary or
ispell-change-dictionary to set the one I wanted, just like with
aspell.

I assume that ispell-parse-hunspell-affix-file is called whenever you
change dictionary, so this shouldn't break anything.

Whatever, I'll try writing up what I've learnt on emacswiki.org since
all the information on the internet seems to be somewhat out of date
and unhelpful.

Thanks!
--
Alan Third
Eli Zaretskii
2015-05-22 19:22:55 UTC
Permalink
Date: Fri, 22 May 2015 19:57:17 +0100
Post by Eli Zaretskii
Date: Thu, 21 May 2015 21:19:19 +0100
Post by Eli Zaretskii
Date: Thu, 21 May 2015 09:16:00 +0100
This works in windows! Once this is done I can then use
ispell-change-dictionary to change the dictionary to anything I want.
Presumably, then, the problem I'm seeing is that ispell+hunspell falls
over if the dictionary initially set by emacs doesn't exist.
OK, I was completely wrong here.
In what way?
Well, it seems the above is right on Windows but wrong on OS X. On
Windows it tries to set the dictionary to "ENG", because that's what
emacs puts in LANG, but on OS X it never gets as far as setting a
dictionary because there's nothing at all in LANG and emacs doesn't
automatically set it.
What about LC_ALL and LC_MESSAGES, do they specify anything on OS X?
What confuses this on OS X is that when you run hunspell from the
command line LANG *IS* set and so it works, but from within emacs (run
from the GUI) LANG *ISN'T* set so it fails.
Ah, so this is somehow related to the shell environment not being
propagated to Emacs. IOW, an OS X specific issue that has nothing to
do with ispell.el or Hunspell. I'm sure there's a way to have these
defined in Emacs, I just cannot help you with that, as I don't know
anything about OS X setup.
Post by Eli Zaretskii
Post by Eli Zaretskii
First, you can customize the variable ispell-dictionary to name the
dictionary (without the .aff or .dic extensions, just the stem of the
basename, as in "en_GB"). You can set this in your ~/.emacs. This
will cause ispell.el to invoke Hunspell with the appropriate -d
command-line option.
This doesn't work. I've done some digging in ispell.el and I think I
know what's going on.
The function ispell-find-hunspell-dictionaries parses the output of
`hunspell -D` looking for *hunspell's* default dictionary. If you
don't have any of the variables you mentioned set then hunspell
doesn't give a default.
What does your Hunspell say when you invoke it with -D? Mine says
<snip>
Post by Eli Zaretskii
Note that the default dictionary it loaded, as announced near the end.
.;;C:\Hunspell\;c:/users/thirda\.openoffice.org\3\user\wordbook;c:\Users\thirda\local\bin\..\share\hunspell;C:\Program
files\OpenOffice.org 2.4\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.3\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.2\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.1\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.0\share\dict\ooo\
c:\Users\thirda\local\bin\..\share\hunspell\default
c:\Users\thirda\local\bin\..\share\hunspell\en_GB
c:\Users\thirda\local\bin\..\share\hunspell\en_US
Can't open affix or dictionary files for dictionary named "ENG".
Creating an "ENG" dictionary fixes this.
See, you don't have the "default" dictionary.
.::/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/Users/alan/.openoffice.org/3/user/wordbook::/Users/alan/.openoffice.org2/user/wordbook::/Users/alan/.openoffice.org2.0/user/wordbook::/Users/alan/Library/Spelling:/opt/openoffice.org/basis3.0/share/dict/ooo:/usr/lib/openoffice.org/basis3.0/share/dict/ooo:/opt/openoffice.org2.4/share/dict/ooo:/usr/lib/openoffice.org2.4/share/dict/ooo:/opt/openoffice.org2.3/share/dict/ooo:/usr/lib/openoffice.org2.3/share/dict/ooo:/opt/openoffice.org2.2/share/dict/ooo:/usr/lib/openoffice.org2.2/share/dict/ooo:/opt/openoffice.org2.1/share/dict/ooo:/usr/lib/openoffice.org2.1/share/dict/ooo:/opt/openoffice.org2.0/share/dict/ooo:/usr/lib/openoffice.org2.0/share/dict/ooo
/Library/Spelling/en_GB
Can't open affix or dictionary files for dictionary named "default".
And the same here.
(getenv "LANG")
returns nil.
Create "default" instead, and I think it will work.
Post by Eli Zaretskii
Once again, I ask where you got your Hunspell binary. In the binary
http://sourceforge.net/projects/ezwinports/files/hunspell-1.3.2-3-w32-bin.zip/download
That's the one I'm using on Windows.
That one has the "default" dictionary, but you don't. How come?
And I've just worked out where I need to put a default dictionary to
get it to work: /usr/share/myspell.
On what OS? On Windows it should be in share/hunspell/.
That's why I wasn't sure if you'd think it was a bug. :)
Did you try to create default.aff and default.dic, as I suggested? I
think that's your problem.
Alan Third
2015-05-22 19:55:52 UTC
Permalink
Post by Eli Zaretskii
Date: Fri, 22 May 2015 19:57:17 +0100
What confuses this on OS X is that when you run hunspell from the
command line LANG *IS* set and so it works, but from within emacs (run
from the GUI) LANG *ISN'T* set so it fails.
Ah, so this is somehow related to the shell environment not being
propagated to Emacs. IOW, an OS X specific issue that has nothing to
do with ispell.el or Hunspell. I'm sure there's a way to have these
defined in Emacs, I just cannot help you with that, as I don't know
anything about OS X setup.
No, I wouldn't expect you to. It seems to be something of a known
problem as Apple removed the ability to set global environment
variables a few versions ago.

Sorry for confusing matters with this.
Post by Eli Zaretskii
.;;C:\Hunspell\;c:/users/thirda\.openoffice.org\3\user\wordbook;c:\Users\thirda\local\bin\..\share\hunspell;C:\Program
files\OpenOffice.org 2.4\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.3\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.2\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.1\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.0\share\dict\ooo\
c:\Users\thirda\local\bin\..\share\hunspell\default
c:\Users\thirda\local\bin\..\share\hunspell\en_GB
c:\Users\thirda\local\bin\..\share\hunspell\en_US
Can't open affix or dictionary files for dictionary named "ENG".
Creating an "ENG" dictionary fixes this.
See, you don't have the "default" dictionary.
Look again, I do. Emacs has set LANG to "ENG" so hunspell is ignoring
"default".

And, again, copying en_GB to ENG solves it. I can deal with this.
Post by Eli Zaretskii
And I've just worked out where I need to put a default dictionary to
get it to work: /usr/share/myspell.
On what OS? On Windows it should be in share/hunspell/.
Sorry, on OS X.

I feel that the way ispell handles a misconfigured hunspell is, at the
moment, not very helpful. I can provide a patch that I believe makes
it fail more gracefully, but I'm getting the feeling it's behaviour
that's not wanted.

Shall we call it quits?

Thanks and apologies for any frustration caused.
--
Alan Third
Eli Zaretskii
2015-05-22 20:08:49 UTC
Permalink
Date: Fri, 22 May 2015 20:55:52 +0100
Post by Eli Zaretskii
Post by Alan Third
.;;C:\Hunspell\;c:/users/thirda\.openoffice.org\3\user\wordbook;c:\Users\thirda\local\bin\..\share\hunspell;C:\Program
files\OpenOffice.org 2.4\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.3\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.2\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.1\share\dict\ooo\;C:\Program
files\OpenOffice.org 2.0\share\dict\ooo\
c:\Users\thirda\local\bin\..\share\hunspell\default
c:\Users\thirda\local\bin\..\share\hunspell\en_GB
c:\Users\thirda\local\bin\..\share\hunspell\en_US
Can't open affix or dictionary files for dictionary named "ENG".
Creating an "ENG" dictionary fixes this.
See, you don't have the "default" dictionary.
Look again, I do.
Oops, sorry.
Emacs has set LANG to "ENG" so hunspell is ignoring "default".
That's OK, and is not a problem. You need "default" for when Emacs
invokes Hunspell with "-d default", and also for invoking it from the
shell.
And, again, copying en_GB to ENG solves it. I can deal with this.
Right, but then I don't understand why the other methods I mentioned
didn't work for you. They do for me.

But perhaps it is not important anymore.
Shall we call it quits?
Probably.
Jan D.
2015-05-22 21:46:14 UTC
Permalink
Post by Alan Third
No, I wouldn't expect you to. It seems to be something of a known
problem as Apple removed the ability to set global environment
variables a few versions ago.
Use launchctl setenv.

Jan D.

Loading...