bug#19229: ispell-phaf: No matching entry for ...

bug#19229: ispell-phaf: No matching entry for ...

[Alexander Shukaev]

[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]

Wasted the whole day on trying to make Hunspell work with Emacs on Windows
and still out of luck.

(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
> SEARCH PATH:
> .;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
> AVAILABLE DICTIONARIES (path is not mandatory for -d option):
> LOADED DICTIONARY:
> C:/Tools/x64/MSYS2/mingw64/share/hunspell/en_US.aff
> C:/Tools/x64/MSYS2/mingw64/share/hunspell/en_US.dic
> Hunspell 1.3.3


I keep getting:

ispell-phaf: No matching entry for ...


and it's no surprise because `ispell-hunspell-dict-paths-alist' is `nil'.
Why?

[-- Attachment #2: Type: text/html, Size: 1719 bytes --]

bug#19229: A workaround for hunspell

[Chris Zheng]

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.

bug#19229: A workaround for hunspell

[Eli Zaretskii]

> Date: Mon, 01 Dec 2014 03:50:50 +0800
> From: Chris Zheng <chriszheng99@gmail.com>
> Cc: haroogan@gmail.com
> 
> 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.)

bug#19229: ispell-phaf: No matching entry for ...

[Eli Zaretskii]

> Date: Sun, 30 Nov 2014 19:25:45 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> 
> 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
>     SEARCH PATH:
>     .;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
>    
>     AVAILABLE DICTIONARIES (path is not mandatory for -d option):
      ^^^^^^^^^^^^^^^^^^^^^^
Why is this list empty?

>     LOADED DICTIONARY:
>     C:/Tools/x64/MSYS2/mingw64/share/hunspell/en_US.aff
>     C:/Tools/x64/MSYS2/mingw64/share/hunspell/en_US.dic
>     Hunspell 1.3.3
> 
> I keep getting:
> 
>     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.

bug#19229: ispell-phaf: No matching entry for ...

[Alexander Shukaev]

[-- Attachment #1: Type: text/plain, Size: 3797 bytes --]

Thanks a lot for the tip.

I don't know what was wrong with MSYS2 version of hunspell, but this one
works with the following minimal configuration:

(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)))


Nevertheless, I can still see

ispell-phaf: No matching entry for nil


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.

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. Here are
a few reasons:

   1. Not all distributions of hunspell even supply "share/hunspell/*"
   stuff with them;
   2. 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.

For instance, #2 is exactly what I was planning to do:

  (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'?

How about redesign?

[-- Attachment #2: Type: text/html, Size: 8878 bytes --]

bug#19229: ispell-phaf: No matching entry for ...

[Eli Zaretskii]

> Date: Sun, 30 Nov 2014 22:55:17 +0100
> From: Alexander Shukaev <haroogan@gmail.com>
> Cc: 19229@debbugs.gnu.org
> 
> Thanks a lot for the tip.
> 
> I don't know what was wrong with MSYS2 version of hunspell, but this one works with the following minimal configuration:
> 
>     (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.

> For instance, #2 is exactly what I was planning to do:
>
>       (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?

bug#19229: ispell-phaf: No matching entry for ...

[Alexander Shukaev]

[-- Attachment #1: Type: text/plain, Size: 215 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 577 bytes --]

bug#19229: ispell on Windows

[Alan Third]

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

bug#19229: ispell on Windows

[Eli Zaretskii]

> Date: Wed, 20 May 2015 19:53:22 +0100
> From: Alan Third <alan@idiocy.org>
> 
> 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.

bug#19229: ispell on Windows

[Alan Third]

On 20 May 2015 at 20:21, Eli Zaretskii <eliz@gnu.org> wrote:
> 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.

> 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.

> 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.

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

bug#19229: ispell on Windows

[Eli Zaretskii]

> Date: Wed, 20 May 2015 21:34:51 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 19229@debbugs.gnu.org
> 
> > 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.

> > 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.
> 
> Unfortunately this doesn't work, I get our old friend:
> 
>   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.

> And if I run it a second time I get:
> 
>   (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.

bug#19229: ispell on Windows

[Alan Third]

On 21 May 2015 at 03:41, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 20 May 2015 21:34:51 +0100
>> From: Alan Third <alan@idiocy.org>
>> Cc: 19229@debbugs.gnu.org
>>
>> > 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

On 21 May 2015 at 03:41, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 20 May 2015 21:34:51 +0100
>> From: Alan Third <alan@idiocy.org>
>> Cc: 19229@debbugs.gnu.org
>>
>> > 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.
>
>> > 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.
>>
>> Unfortunately this doesn't work, I get our old friend:
>>
>>   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.
>
>> And if I run it a second time I get:
>>
>>   (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

bug#19229: ispell on Windows

[Eli Zaretskii]

> Date: Thu, 21 May 2015 09:16:00 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 19229@debbugs.gnu.org
> 
> >> > 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.

bug#19229: ispell on Windows

[Alan Third]

On 21 May 2015 at 17:23, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 21 May 2015 09:16:00 +0100
>> From: Alan Third <alan@idiocy.org>
>> Cc: 19229@debbugs.gnu.org
>>
>> 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.

>> 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.

> 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

bug#19229: ispell on Windows

[Eli Zaretskii]

> Date: Thu, 21 May 2015 21:19:19 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 19229@debbugs.gnu.org
> 
> On 21 May 2015 at 17:23, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Thu, 21 May 2015 09:16:00 +0100
> >> From: Alan Third <alan@idiocy.org>
> >> Cc: 19229@debbugs.gnu.org
> >>
> >> 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?

> >> 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.

bug#19229: ispell on Windows

[Alan Third]

On 22 May 2015 at 07:53, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 21 May 2015 21:19:19 +0100
>> From: Alan Third <alan@idiocy.org>
>> Cc: 19229@debbugs.gnu.org
>>
>> On 21 May 2015 at 17:23, Eli Zaretskii <eliz@gnu.org> wrote:
>> >> Date: Thu, 21 May 2015 09:16:00 +0100
>> >> From: Alan Third <alan@idiocy.org>
>> >> Cc: 19229@debbugs.gnu.org
>> >>
>> >> 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.

>> > 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:
>
<snip>
>
> 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.

> 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

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.

>> 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

bug#19229: ispell on Windows

[Eli Zaretskii]

> Date: Fri, 22 May 2015 19:57:17 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 19229@debbugs.gnu.org
> 
> On 22 May 2015 at 07:53, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Thu, 21 May 2015 21:19:19 +0100
> >> From: Alan Third <alan@idiocy.org>
> >> Cc: 19229@debbugs.gnu.org
> >>
> >> On 21 May 2015 at 17:23, Eli Zaretskii <eliz@gnu.org> wrote:
> >> >> Date: Thu, 21 May 2015 09:16:00 +0100
> >> >> From: Alan Third <alan@idiocy.org>
> >> >> Cc: 19229@debbugs.gnu.org
> >> >>
> >> >> 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.

> >> > 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:
> >
> <snip>
> >
> > 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.

See, you don't have the "default" dictionary.

> 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".

And the same here.

> Creating an ENG dictionary doesn't help here because:
> 
> (getenv "LANG")
> 
> returns nil.

Create "default" instead, and I think it will work.

> > 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
> 
> 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.

bug#19229: ispell on Windows

[Alan Third]

On 22 May 2015 at 20:22, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 22 May 2015 19:57:17 +0100
>> From: Alan Third <alan@idiocy.org>
>> Cc: 19229@debbugs.gnu.org
>>
>> 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.

>> 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.
>
> 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.

>> 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

bug#19229: ispell on Windows

[Eli Zaretskii]

> Date: Fri, 22 May 2015 20:55:52 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 19229@debbugs.gnu.org
> 
> >> 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.
> >
> > 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.

bug#19229: ispell on Windows

[Jan D.]

> 22 maj 2015 kl. 21:55 skrev Alan Third <alan@idiocy.org>:

> 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.

bug#19229: ispell on Windows

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

> 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?

Reading this thread, it seems like hunspell doesn't work out of the box
on some systems in Emacs.  If Alan has a fix that improves the
user experience here, that would surely be useful?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#19229: ispell on Windows

[Alan Third]

On Mon, Sep 07, 2020 at 11:55:44PM +0200, Lars Ingebrigtsen wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> > 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?
> 
> Reading this thread, it seems like hunspell doesn't work out of the box
> on some systems in Emacs.  If Alan has a fix that improves the
> user experience here, that would surely be useful?

Oh, this was so long ago I've no idea what my fix was any more. I'd
assumed this bug report had been closed.

-- 
Alan Third

bug#19229: ispell on Windows

[Lars Ingebrigtsen]

Alan Third <alan@idiocy.org> writes:

>> Reading this thread, it seems like hunspell doesn't work out of the box
>> on some systems in Emacs.  If Alan has a fix that improves the
>> user experience here, that would surely be useful?
>
> Oh, this was so long ago I've no idea what my fix was any more. I'd
> assumed this bug report had been closed.

OK; then it seems unlikely we'll make further progress in this bug
report, and I'm closing it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no