From: Kisaragi Hiu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: 49982@debbugs.gnu.org
Subject: bug#49982: 27.2; ispell.el fails to find a Hunspell dictionary to use as default despite ispell-dictionary being set
Date: Wed, 11 Aug 2021 00:12:06 +0900 [thread overview]
Message-ID: <59517c95-6568-f646-7097-c601cc9657c9@kisaragi-hiu.com> (raw)
This configuration should be everything that's needed for ispell.el to
work with Hunspell, regardless of system locale:
(setq ispell-program-name (executable-find "hunspell")
ispell-dictionary "en_US"))
However, when system locale (the LANG environment variable) does not
have a corresponding Hunspell dictionary,
`ispell-find-hunspell-dictionaries` returns the error "Can't find
Hunspell dictionary with a .aff affix file", despite ispell-dictionary
being set.
ispell.el relies on Hunspell to load a default and report it, but
Hunspell just errors out if it can't find a dictionary for the system
locale. And because ispell.el is trying to get Hunspell's default
dictionary, it doesn't pass `ispell-dictionary' onto Hunspell.
This behavior is surprising. If `ispell-dictionary` is non-nil, that
means the user has already specified their preferred dictionary, and it
should not matter that Hunspell cannot find the dictionary it would use
when a preferred dictionary isn't specified.
It's ispell.el that needs to be fixed here because the user specifies
their preference in Emacs, and it is its job to communicate that
preference to Hunspell.
`ispell-find-hunspell-dictionaries` should pass "-d
${ispell-dictionary}" to Hunspell if `ispell-dictionary` is set. This
invocation:
hunspell -d "en_US" -D /dev/null
works as expected regardless of the system locale.
* System info
In GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.27,
cairo version 1.17.4) of 2021-03-27 built on juergen Windowing system
distributor 'The X.Org Foundation', version 11.0.12013000 System
Description: Arch Linux
Hunspell 1.7.0; hunspell -D is
SEARCH PATH:
.::/usr/share/hunspell:/usr/share/myspell:/usr/share/myspell/dicts:/Library/Spelling:/home/kisaragi-hiu/.openoffice.org/3/user/wordbook:/home/kisaragi-hiu/.openoffice.org2/user/wordbook:/home/kisaragi-hiu/.openoffice.org2.0/user/wordbook:/home/kisaragi-hiu/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):
... [truncated]
/usr/share/hunspell/en_US-large
... [truncated]
* Reproduction
- Notice how Hunspell does not return LOADED DICTIONARY under, for
example, ja_JP:
export LANG=ja_JP
hunspell -D /dev/null
# Output:
# ... [truncated]
# Can't open affix or dictionary files for dictionary named "ja_JP".
- Now, in Emacs with LANG set to ja_JP, set ispell up with Hunspell as
usual.
(setq ispell-program-name (executable-find "hunspell")
ispell-dictionary "en_US"))
- Observe the error.
(ispell-start-process)
;; -> ispell-find-hunspell-dictionaries: Can^[$B!G^[(Bt find Hunspell
dictionary with a .aff affix file
next reply other threads:[~2021-08-10 15:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-10 15:12 Kisaragi Hiu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2021-08-10 16:03 ` bug#49982: 27.2; ispell.el fails to find a Hunspell dictionary to use as default despite ispell-dictionary being set Eli Zaretskii
2021-08-10 18:51 ` Kisaragi Hiu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-10 19:29 ` Eli Zaretskii
2021-08-11 11:17 ` Kisaragi Hiu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-11 12:12 ` Eli Zaretskii
2022-08-22 12:57 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59517c95-6568-f646-7097-c601cc9657c9@kisaragi-hiu.com \
--to=bug-gnu-emacs@gnu.org \
--cc=49982@debbugs.gnu.org \
--cc=mail@kisaragi-hiu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.