* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
@ 2017-02-21 3:41 S W
2020-08-26 18:09 ` Stefan Kangas
0 siblings, 1 reply; 16+ messages in thread
From: S W @ 2017-02-21 3:41 UTC (permalink / raw)
To: 25825
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))
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2017-02-21 3:41 bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows S W
@ 2020-08-26 18:09 ` Stefan Kangas
2020-08-26 18:28 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2020-08-26 18:09 UTC (permalink / raw)
To: S W; +Cc: 25825
[-- 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)
^ permalink raw reply related [flat|nested] 16+ messages in thread* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 18:09 ` Stefan Kangas
@ 2020-08-26 18:28 ` Eli Zaretskii
2020-08-26 18:34 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Eli Zaretskii @ 2020-08-26 18:28 UTC (permalink / raw)
To: Stefan Kangas; +Cc: sw9, 25825
> 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?
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 18:28 ` Eli Zaretskii
@ 2020-08-26 18:34 ` Eli Zaretskii
2020-08-27 4:32 ` Stefan Kangas
2020-08-26 18:36 ` Eli Zaretskii
2020-08-26 18:48 ` Stefan Kangas
2 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2020-08-26 18:34 UTC (permalink / raw)
To: stefan, sw9; +Cc: 25825
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 18:34 ` Eli Zaretskii
@ 2020-08-27 4:32 ` Stefan Kangas
2020-11-24 8:43 ` Lars Ingebrigtsen
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2020-08-27 4:32 UTC (permalink / raw)
To: Eli Zaretskii, sw9; +Cc: 25825
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-27 4:32 ` Stefan Kangas
@ 2020-11-24 8:43 ` Lars Ingebrigtsen
0 siblings, 0 replies; 16+ messages in thread
From: Lars Ingebrigtsen @ 2020-11-24 8:43 UTC (permalink / raw)
To: Stefan Kangas; +Cc: sw9, 25825
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 18:28 ` Eli Zaretskii
2020-08-26 18:34 ` Eli Zaretskii
@ 2020-08-26 18:36 ` Eli Zaretskii
2020-08-26 18:48 ` Stefan Kangas
2020-08-26 18:48 ` Stefan Kangas
2 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2020-08-26 18:36 UTC (permalink / raw)
To: stefan; +Cc: sw9, 25825
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 18:36 ` Eli Zaretskii
@ 2020-08-26 18:48 ` Stefan Kangas
2020-08-26 18:59 ` Eli Zaretskii
0 siblings, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2020-08-26 18:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: sw9, 25825
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".
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 18:48 ` Stefan Kangas
@ 2020-08-26 18:59 ` Eli Zaretskii
2020-08-26 19:21 ` Stefan Kangas
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2020-08-26 18:59 UTC (permalink / raw)
To: Stefan Kangas; +Cc: sw9, 25825
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 18:59 ` Eli Zaretskii
@ 2020-08-26 19:21 ` Stefan Kangas
2020-08-26 19:39 ` Eli Zaretskii
2020-08-26 20:01 ` Stefan Kangas
0 siblings, 2 replies; 16+ messages in thread
From: Stefan Kangas @ 2020-08-26 19:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: sw9, 25825
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?
^ permalink raw reply [flat|nested] 16+ messages in thread* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 19:21 ` Stefan Kangas
@ 2020-08-26 19:39 ` Eli Zaretskii
2020-08-26 20:10 ` Stefan Kangas
2020-08-26 20:01 ` Stefan Kangas
1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2020-08-26 19:39 UTC (permalink / raw)
To: Stefan Kangas; +Cc: sw9, 25825
> 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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 19:39 ` Eli Zaretskii
@ 2020-08-26 20:10 ` Stefan Kangas
0 siblings, 0 replies; 16+ messages in thread
From: Stefan Kangas @ 2020-08-26 20:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: sw9, 25825
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 19:21 ` Stefan Kangas
2020-08-26 19:39 ` Eli Zaretskii
@ 2020-08-26 20:01 ` Stefan Kangas
2020-08-27 3:27 ` Eli Zaretskii
1 sibling, 1 reply; 16+ messages in thread
From: Stefan Kangas @ 2020-08-26 20:01 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: sw9, 25825
[-- 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.
^ permalink raw reply related [flat|nested] 16+ messages in thread* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 20:01 ` Stefan Kangas
@ 2020-08-27 3:27 ` Eli Zaretskii
2020-08-27 3:51 ` Stefan Kangas
0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2020-08-27 3:27 UTC (permalink / raw)
To: Stefan Kangas; +Cc: sw9, 25825
> 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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-27 3:27 ` Eli Zaretskii
@ 2020-08-27 3:51 ` Stefan Kangas
0 siblings, 0 replies; 16+ messages in thread
From: Stefan Kangas @ 2020-08-27 3:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: sw9, 25825
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows
2020-08-26 18:28 ` Eli Zaretskii
2020-08-26 18:34 ` Eli Zaretskii
2020-08-26 18:36 ` Eli Zaretskii
@ 2020-08-26 18:48 ` Stefan Kangas
2 siblings, 0 replies; 16+ messages in thread
From: Stefan Kangas @ 2020-08-26 18:48 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: sw9, 25825
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".
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2020-11-24 8:43 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-02-21 3:41 bug#25825: 25.1; ispell-find-hunspell-dictionaries not working on Windows S W
2020-08-26 18:09 ` Stefan Kangas
2020-08-26 18:28 ` Eli Zaretskii
2020-08-26 18:34 ` Eli Zaretskii
2020-08-27 4:32 ` Stefan Kangas
2020-11-24 8:43 ` Lars Ingebrigtsen
2020-08-26 18:36 ` Eli Zaretskii
2020-08-26 18:48 ` Stefan Kangas
2020-08-26 18:59 ` Eli Zaretskii
2020-08-26 19:21 ` Stefan Kangas
2020-08-26 19:39 ` Eli Zaretskii
2020-08-26 20:10 ` Stefan Kangas
2020-08-26 20:01 ` Stefan Kangas
2020-08-27 3:27 ` Eli Zaretskii
2020-08-27 3:51 ` Stefan Kangas
2020-08-26 18:48 ` Stefan Kangas
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).