bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[S W]

I am using hunspell 1.3.2 on Windows from ezwinports.
ispell-find-hunspell-dictionaries isn't setting
ispell-hunspell-dictionary-alist properly because I believe LANG=ENU
is overriding the default dictionary. This results in "Can't open
affix or dictionary files for dictionary named \"ENU\" appearing in
hunspell-found-dicts instead of "default.aff", which results in
hunspell-default-dict being set to nil and an error when
ispell-parse-hunspell-affix-file(hunspell-default-dict) is called.

To reproduce in emacs -q
(setq ispell-program-name "path_to_hunspell")
M-x ispell-buffer

In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-11-15 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Configured using:
 'configure --without-dbus --without-compress-install 'CFLAGS=-O2
 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
split-string: Wrong type argument: stringp, nil

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message idna dired format-spec rfc822
mml mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils ispell time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
w32notify w32 multi-tty make-network-process emacs)

Memory information:
((conses 16 91762 3533)
 (symbols 56 20003 0)
 (miscs 48 91 84)
 (strings 32 17048 5055)
 (string-bytes 1 472329)
 (vectors 16 11965)
 (vector-slots 8 427043 5530)
 (floats 8 160 19)
 (intervals 56 284 37)
 (buffers 976 23))

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Stefan Kangas]

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

S W <sw9@outlook.com> writes:

> I am using hunspell 1.3.2 on Windows from ezwinports.
> ispell-find-hunspell-dictionaries isn't setting
> ispell-hunspell-dictionary-alist properly because I believe LANG=ENU
> is overriding the default dictionary. This results in "Can't open
> affix or dictionary files for dictionary named \"ENU\" appearing in
> hunspell-found-dicts instead of "default.aff", which results in
> hunspell-default-dict being set to nil and an error when
> ispell-parse-hunspell-affix-file(hunspell-default-dict) is called.
>
> To reproduce in emacs -q
> (setq ispell-program-name "path_to_hunspell")
> M-x ispell-buffer
>
> In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
>  of 2016-11-15 built on LAPHROAIG
> Windowing system distributor 'Microsoft Corp.', version 10.0.14393
> Configured using:
>  'configure --without-dbus --without-compress-install 'CFLAGS=-O2
>  -static -g3''

First, I can reproduce the issue using current master on Debian
GNU/Linux (bullseye/sid) with the following steps:

    0. emacs -Q
    1. (setq ispell-program-name "hunspell")
    2. M-x ispell-buffer

The error is "Can't find Hunspell dictionary with a .aff affix file" and
comes from `ispell-find-hunspell-dictionaries'.

Looking at `ispell-find-hunspell-dictionaries', I don't see how it would
work at all.  It is using the output from "hunspell -D", and will only
set the local variable `hunspell-default-dict' if any of the output
lines match ".aff$".

But the output from "hunspell -D" looks like this on my machine:

    $ hunspell -D
    SEARCH PATH:
    .::/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/home/skangas/.openoffice.org/3/user/wordbook:/home/skangas/.openoffice.org2/user/wordbook:/home/skangas/.openoffice.org2.0/user/wordbook:/home/skangas/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):
    /usr/share/hunspell/en_US
    /usr/share/hunspell/sv_FI
    /usr/share/hunspell/sv_SE
    /home/skangas/.openoffice.org/3/user/wordbook/standard

So we never set `hunspell-default-dict', and we therefore barf here:

    (or hunspell-default-dict
        (error "Can't find Hunspell dictionary with a .aff affix file"))

Eli, I see that you have done some work here, could you perhaps shed
some light on how this is all supposed to work?

(I would also suggest to install the attached patch to immediately
filter out the useless lines "SEARCH PATH", "AVAILABLE DICTIONARIES",
etc.)

Best regards,
Stefan Kangas

[-- Attachment #2: bug-25825.diff --]
[-- Type: text/x-diff, Size: 2434 bytes --]

diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el
index 6eaa0582aa..0240ef50bd 100644
--- a/lisp/textmodes/ispell.el
+++ b/lisp/textmodes/ispell.el
@@ -1096,28 +1096,30 @@ ispell-find-hunspell-dictionaries
 in `ispell-dicts-name2locale-equivs-alist' if an explicit
 dictionary from that list was found."
   (let ((hunspell-found-dicts
-	 (split-string
-	  (with-temp-buffer
-	    (ispell-call-process ispell-program-name
-				 null-device
-				 t
-				 nil
-                                 "-D"
-                                 ;; Use -a to prevent Hunspell from
-                                 ;; trying to initialize its
-                                 ;; curses/termcap UI, which causes it
-                                 ;; to crash or fail to start in some
-                                 ;; MS-Windows ports.
-                                 "-a"
-                                 ;; Hunspell 1.7.0 (and later?) won't
-                                 ;; show LOADED DICTIONARY unless
-                                 ;; there's at least one file argument
-                                 ;; on the command line.  So we feed
-                                 ;; it with the null device.
-				 null-device)
-	    (buffer-string))
-	  "[\n\r]+"
-	  t))
+         (seq-filter
+          #'file-name-absolute-p
+          (split-string
+           (with-temp-buffer
+             (ispell-call-process ispell-program-name
+                            null-device
+                            t
+                            nil
+                            "-D"
+                            ;; Use -a to prevent Hunspell from
+                            ;; trying to initialize its
+                            ;; curses/termcap UI, which causes it
+                            ;; to crash or fail to start in some
+                            ;; MS-Windows ports.
+                            "-a"
+                            ;; Hunspell 1.7.0 (and later?) won't
+                            ;; show LOADED DICTIONARY unless
+                            ;; there's at least one file argument
+                            ;; on the command line.  So we feed
+                            ;; it with the null device.
+                            null-device)
+             (buffer-string))
+           "[\n\r]+"
+           t)))
 	hunspell-default-dict
 	hunspell-default-dict-entry
 	hunspell-multi-dict)

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 26 Aug 2020 11:09:21 -0700
> Cc: 25825@debbugs.gnu.org
> 
> Looking at `ispell-find-hunspell-dictionaries', I don't see how it would
> work at all.  It is using the output from "hunspell -D", and will only
> set the local variable `hunspell-default-dict' if any of the output
> lines match ".aff$".
> 
> But the output from "hunspell -D" looks like this on my machine:
> 
>     $ hunspell -D
>     SEARCH PATH:
>     .::/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/home/skangas/.openoffice.org/3/user/wordbook:/home/skangas/.openoffice.org2/user/wordbook:/home/skangas/.openoffice.org2.0/user/wordbook:/home/skangas/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):
>     /usr/share/hunspell/en_US
>     /usr/share/hunspell/sv_FI
>     /usr/share/hunspell/sv_SE
>     /home/skangas/.openoffice.org/3/user/wordbook/standard

Hunspell is supposed to display this at the end of the "available
dictionaries" output:

  LOADED DICTIONARY:
  /usr/share/hunspell/default.aff
  /usr/share/hunspell/default.dic

(The "default" part can be different in your case.)

The Hunspell I have does show this.  If yours doesn't, perhaps they've
changed the output in later versions, in which case we need to figure
out how to force the newer Hunspell to output the loaded dictionary.
Because just knowing what dictionaries are available is not enough.

So please read the man page for Hunspell you have, and tell how to ask
Hunspell for that missing part.  Note that the code already includes a
quirk for Hunspell 1.7.0, maybe it doesn't work with later versions?

In any case, this cannot be the reason for the OP's problem, because
he evidently uses the same version of Hunspell that I do (the
ezwinports site is where I upload the ports I use myself).

> (I would also suggest to install the attached patch to immediately
> filter out the useless lines "SEARCH PATH", "AVAILABLE DICTIONARIES",
> etc.)

I don't think I understand the reason.  Why should we care what else
does Hunspell output in this case?

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Eli Zaretskii]

> Date: Wed, 26 Aug 2020 21:28:11 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: sw9@outlook.com, 25825@debbugs.gnu.org
> 
> In any case, this cannot be the reason for the OP's problem, because
> he evidently uses the same version of Hunspell that I do (the
> ezwinports site is where I upload the ports I use myself).

FWIW, my crystal ball says that OP's problem is a simple cockpit
error: the OP should copy en_US.aff and en_US.dic to ENU.aff and
ENU.doc, respectively, and things will start working.  This renaming
is needed because Windows locales are named using a different naming
scheme than on Posix hosts.

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Eli Zaretskii]

> Date: Wed, 26 Aug 2020 21:28:11 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: sw9@outlook.com, 25825@debbugs.gnu.org
> 
> > But the output from "hunspell -D" looks like this on my machine:
> > 
> >     $ hunspell -D

What does it show if you use

  $ hunspell -D /dev/null

Because the latter is how Emacs invokes Hunspell, note the null-device
part of the command we invoke.

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Hunspell is supposed to display this at the end of the "available
> dictionaries" output:
>
>   LOADED DICTIONARY:
>   /usr/share/hunspell/default.aff
>   /usr/share/hunspell/default.dic
>
> (The "default" part can be different in your case.)
>
> The Hunspell I have does show this.  If yours doesn't, perhaps they've
> changed the output in later versions, in which case we need to figure
> out how to force the newer Hunspell to output the loaded dictionary.
> Because just knowing what dictionaries are available is not enough.
>
> So please read the man page for Hunspell you have, and tell how to ask
> Hunspell for that missing part.  Note that the code already includes a
> quirk for Hunspell 1.7.0, maybe it doesn't work with later versions?

Right, I'm using:

@(#) International Ispell Version 3.2.06 (but really Hunspell 1.7.0)

The man page says:

-D Show detected path of the loaded dictionary, and list of the search
 path and the available dictionaries.

>> (I would also suggest to install the attached patch to immediately
>> filter out the useless lines "SEARCH PATH", "AVAILABLE DICTIONARIES",
>> etc.)
>
> I don't think I understand the reason.  Why should we care what else
> does Hunspell output in this case?

It makes the intention clearer, and makes it slightly easier to debug.

As it stands, when you step through this, we begin with looking for
"SEARCH PATH:.aff".

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> What does it show if you use
>
>   $ hunspell -D /dev/null
>
> Because the latter is how Emacs invokes Hunspell, note the null-device
> part of the command we invoke.

Hmm... So there is an error which is not there for "hunspell -D".

I'll investigate.

$ hunspell -D /dev/null
SEARCH PATH:
.::/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/home/skangas/.openoffice.org/3/user/wordbook:/home/skangas/.openoffice.org2/user/wordbook:/home/skangas/.openoffice.org2.0/user/wordbook:/home/skangas/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):
/usr/share/hunspell/en_US
/usr/share/hunspell/sv_FI
/usr/share/hunspell/sv_SE
/home/skangas/.openoffice.org/3/user/wordbook/standard
Can't open affix or dictionary files for dictionary named "default".

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 26 Aug 2020 11:48:20 -0700
> Cc: sw9@outlook.com, 25825@debbugs.gnu.org
> 
> AVAILABLE DICTIONARIES (path is not mandatory for -d option):
> /usr/share/hunspell/en_US
> /usr/share/hunspell/sv_FI
> /usr/share/hunspell/sv_SE
> /home/skangas/.openoffice.org/3/user/wordbook/standard
> Can't open affix or dictionary files for dictionary named "default".

Looks like you have an installation problem: there's no default.dic on
your system.

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> Looks like you have an installation problem: there's no default.dic on
> your system.

It seems to be an issue with my environment.  I've been using this for a
very long time:

    $ locale
    LANG=
    LANGUAGE=
    LC_CTYPE=sv_SE.UTF-8
    LC_NUMERIC="POSIX"
    LC_TIME=C
    LC_COLLATE=C
    LC_MONETARY="POSIX"
    LC_MESSAGES="POSIX"
    LC_PAPER="POSIX"
    LC_NAME="POSIX"
    LC_ADDRESS="POSIX"
    LC_TELEPHONE="POSIX"
    LC_MEASUREMENT="POSIX"
    LC_IDENTIFICATION="POSIX"
    LC_ALL=

But for some reason, hunspell is very sensitive and will not give any
loaded dictionary if $LANG is unset.  (IMO, very unhelpful behaviour.)

This gives the expected output:

    $ export LANG=en_US.UTF-8
    $ hunspell -D /dev/null
    SEARCH PATH:
    [[...snipped...]]
    AVAILABLE DICTIONARIES (path is not mandatory for -d option):
    /usr/share/hunspell/en_US
    /usr/share/hunspell/sv_FI
    /usr/share/hunspell/sv_SE
    /home/skangas/.openoffice.org/3/user/wordbook/standard
    LOADED DICTIONARY:
    /usr/share/hunspell/en_US.aff
    /usr/share/hunspell/en_US.dic

One idea to improve the situation on our end is to look for "Can't
open affix or dictionary files for dictionary named 'default'." and
raise a better error in these cases.

Or, if we want to really go out of our way, we could retry with
"LANG=en_US.UTF-8".

WDYT?

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 26 Aug 2020 12:21:02 -0700
> Cc: sw9@outlook.com, 25825@debbugs.gnu.org
> 
> But for some reason, hunspell is very sensitive and will not give any
> loaded dictionary if $LANG is unset.  (IMO, very unhelpful behaviour.)

Maybe this is worth a bug report against Hunspell.  But is this really
relevant to how Hunspell is invoked from Emacs?  It certainly isn't on
Windows, because we inject LANG into the environment there.  But what
about Posix hosts?

> One idea to improve the situation on our end is to look for "Can't
> open affix or dictionary files for dictionary named 'default'." and
> raise a better error in these cases.

Fine with me.

> Or, if we want to really go out of our way, we could retry with
> "LANG=en_US.UTF-8".

That cannot fly: we cannot second-guess the user's locale, and we
shouldn't force some arbitrary locale on them.  It's basically a
mis-configured system, so signaling an error is good enough, IMO.

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Stefan Kangas]

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

Stefan Kangas <stefan@marxist.se> writes:

> It seems to be an issue with my environment.  I've been using this for a
> very long time:
>
>     $ locale
>     LANG=

So, I looked into all my locale stuff again, and it turns out that $LANG
was unintentionally left unset here for boring reasons.  (There is no
reason to leave $LANG unset.)

> One idea to improve the situation on our end is to look for "Can't
> open affix or dictionary files for dictionary named 'default'." and
> raise a better error in these cases.

I think it's better to raise the more helpful error.

How does the attached diff look?

[-- Attachment #2: bug-25825-2.diff --]
[-- Type: text/x-diff, Size: 3819 bytes --]

diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el
index 6eaa0582aa..6e7eb0fb5e 100644
--- a/lisp/textmodes/ispell.el
+++ b/lisp/textmodes/ispell.el
@@ -1096,28 +1096,38 @@ ispell-find-hunspell-dictionaries
 in `ispell-dicts-name2locale-equivs-alist' if an explicit
 dictionary from that list was found."
   (let ((hunspell-found-dicts
-	 (split-string
-	  (with-temp-buffer
-	    (ispell-call-process ispell-program-name
-				 null-device
-				 t
-				 nil
-                                 "-D"
-                                 ;; Use -a to prevent Hunspell from
-                                 ;; trying to initialize its
-                                 ;; curses/termcap UI, which causes it
-                                 ;; to crash or fail to start in some
-                                 ;; MS-Windows ports.
-                                 "-a"
-                                 ;; Hunspell 1.7.0 (and later?) won't
-                                 ;; show LOADED DICTIONARY unless
-                                 ;; there's at least one file argument
-                                 ;; on the command line.  So we feed
-                                 ;; it with the null device.
-				 null-device)
-	    (buffer-string))
-	  "[\n\r]+"
-	  t))
+         (seq-filter
+          (lambda (str)
+            (when (string-match
+                   ;; Hunspell gives this error when there is some
+                   ;; installation problem, for example if $LANG is unset.
+                   (concat "^Can't open affix or dictionary files "
+                           "for dictionary named \"default\".$")
+                   str)
+              (user-error "Hunspell error: %s" str))
+            (file-name-absolute-p str))
+          (split-string
+           (with-temp-buffer
+             (ispell-call-process ispell-program-name
+                            null-device
+                            t
+                            nil
+                            "-D"
+                            ;; Use -a to prevent Hunspell from
+                            ;; trying to initialize its
+                            ;; curses/termcap UI, which causes it
+                            ;; to crash or fail to start in some
+                            ;; MS-Windows ports.
+                            "-a"
+                            ;; Hunspell 1.7.0 (and later?) won't
+                            ;; show LOADED DICTIONARY unless
+                            ;; there's at least one file argument
+                            ;; on the command line.  So we feed
+                            ;; it with the null device.
+                            null-device)
+             (buffer-string))
+           "[\n\r]+"
+           t)))
 	hunspell-default-dict
 	hunspell-default-dict-entry
 	hunspell-multi-dict)
@@ -1164,7 +1174,7 @@ ispell-find-hunspell-dictionaries
     (dolist (dict-equiv ispell-dicts-name2locale-equivs-alist)
       (let ((dict-equiv-key (car dict-equiv))
 	    (dict-equiv-value (cadr dict-equiv))
-	    (exclude-aliases (list   ;; Exclude TeX aliases
+	    (exclude-aliases (list ;; Exclude TeX aliases
 			      "esperanto-tex"
 			      "francais7"
 			      "francais-tex"
@@ -1175,7 +1185,7 @@ ispell-find-hunspell-dictionaries
 	    (let ((affix-file (cadr (assoc dict-equiv-value
                                            ispell-hunspell-dict-paths-alist))))
 	      (ispell-print-if-debug "++ ispell-fhd: Adding alias %s -> %s.\n"
-                                     dict-equiv-key affix-file)
+                               dict-equiv-key affix-file)
 	      (cl-pushnew (list dict-equiv-key affix-file)
                           ispell-hunspell-dict-paths-alist :test #'equal)))))
     ;; Parse and set values for default dictionary.

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>> But for some reason, hunspell is very sensitive and will not give any
>> loaded dictionary if $LANG is unset.  (IMO, very unhelpful behaviour.)
>
> Maybe this is worth a bug report against Hunspell.

I filed a bug report against hunspell here:

    https://github.com/hunspell/hunspell/issues/687

> But is this really relevant to how Hunspell is invoked from Emacs?  It
> certainly isn't on Windows, because we inject LANG into the
> environment there.  But what about Posix hosts?

AFAIU, we just inherit the environment such that if $LANG is unset in
the parent process,

    (getenv "LANG") => nil

> That cannot fly: we cannot second-guess the user's locale, and we
> shouldn't force some arbitrary locale on them.  It's basically a
> mis-configured system, so signaling an error is good enough, IMO.

Point taken.

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 26 Aug 2020 13:01:21 -0700
> Cc: sw9@outlook.com, 25825@debbugs.gnu.org
> 
> > One idea to improve the situation on our end is to look for "Can't
> > open affix or dictionary files for dictionary named 'default'." and
> > raise a better error in these cases.
> 
> I think it's better to raise the more helpful error.
> 
> How does the attached diff look?

It's OK, but wouldn't it be more helpful if we added something like

  (is $LANG unset?)

to the error message text?

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> It's OK, but wouldn't it be more helpful if we added something like
>
>   (is $LANG unset?)
>
> to the error message text?

I actually had that at first but removed it for brevity.

But I guess it's worth being more helpful in this exceptional
circumstance, so I'll add it back in.  Thanks.

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Stefan Kangas]

tags 25825 + moreinfo
thanks

Eli Zaretskii <eliz@gnu.org> writes:

>> In any case, this cannot be the reason for the OP's problem, because
>> he evidently uses the same version of Hunspell that I do (the
>> ezwinports site is where I upload the ports I use myself).
>
> FWIW, my crystal ball says that OP's problem is a simple cockpit
> error: the OP should copy en_US.aff and en_US.dic to ENU.aff and
> ENU.doc, respectively, and things will start working.  This renaming
> is needed because Windows locales are named using a different naming
> scheme than on Posix hosts.

S W, could you please try the above and see if that resolves your
problem?

Thanks in advance.

Best regards,
Stefan Kangas

bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> S W, could you please try the above and see if that resolves your
> problem?

This was months ago, and there was no response, so it seems unlikely
that there'll be further progress here, and I'm closing this bug report.
If further progress can be made, please respond to the debbugs address
and we'll reopen.

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