[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#49982: 27.2; ispell.el fails to find a Hunspell dictionary to use as
From: |
Kisaragi Hiu |
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 03:51:22 +0900 |
Thank you for the response! Let me try to add some clarifications (that
hopefully don't sound too harsh):
> First, yours is an unusual use case, I think: when Hunspell is
> installed, the dictionary that corresponds to the locale is always
> installed, because otherwise Hunspell will not work reliably from the
> shell command line.
I'm fairly certain my use case isn't unusual.
There are no easily installable Hunspell dictionaries for, among other
languages:
- Any variant of Chinese (Mandarin)
- Japanese
- Kazakh
- Khmer
- Malay
Every user of any of these languages who tries to set up Hunspell
along with ispell.el and Flyspell has to find or invent a poorly
documented workaround.
- [[https://texwiki.texjp.org/?Hunspell][TeXJP (Japanese) mentions]]
"add[ing] the DICTIONARY or WORDLIST environment variables if needed"
(「また、必要に応じて環境変数DICTIONARYやWORDLISTを指定しておきます。」)
- [[https://home.hirosaki-u.ac.jp/heroic-2020/1575/][Hirosaki University
Information Technology Center PC lab's tutorial to spellchecking in
Emacs]] sets DICTIONARY to en_US
- 200ok.ch (developer of Organice)'s
[[https://200ok.ch/posts/2020-08-22_setting_up_spell_checking_with_multiple_dictionaries.html][tutorial
for using multiple dictionaries for Hunspell + ispell.el]] mentions
;; Configure `LANG`, otherwise ispell.el cannot find a 'default
;; dictionary' even though multiple dictionaries will be configured
;; in next line.
(setenv "LANG" "en_US.UTF-8")
-
[[http://blog.binchen.org/posts/what-s-the-best-spell-check-set-up-in-emacs/][Chen
Bin's blog post on setting up spell check]] uses this block:
;; find aspell and hunspell automatically
(cond
;; try hunspell at first
;; if hunspell does NOT exist, use aspell
((executable-find "hunspell")
(setq ispell-program-name "hunspell")
(setq ispell-local-dictionary "en_US")
(setq ispell-local-dictionary-alist
;; Please note the list `("-d" "en_US")` contains ACTUAL
parameters passed to hunspell
;; You could use `("-d" "en_US,en_US-med")` to check with
multiple dictionaries
'(("en_US" "[[:alpha:]]" "[^[:alpha:]]" "[']" nil ("-d"
"en_US") nil utf-8)))
;; new variable `ispell-hunspell-dictionary-alist' is defined in
Emacs
;; If it's nil, Emacs tries to automatically set up the dictionaries.
(when (boundp 'ispell-hunspell-dictionary-alist)
(setq ispell-hunspell-dictionary-alist
ispell-local-dictionary-alist)))
"Emacs tries to automatically set up the dictionaries" refers to
ispell-set-spellchecker-params running
ispell-find-hunspell-dictionaries after
seeing that ispell-hunspell-dictionary-alist is nil.
My use case is not unusual. Fixing this bug would eliminate the need
for these workarounds.
(From the command line you just pass in -d yourself. Setting environment
variables is also a native way of configuring programs in the CLI; in
Emacs generally wrapper packages like ispell.el define user options
instead of asking users to do `setenv` themselves.)
> And second, relying on the non-nil value of
> ispell-dictionary is fragile: the value could be a remnant from some
> previous invocation or from an unsuccessful customization that has
> nothing to do with the user's choice or his/her current intent.
ispell-dictionary is a user option, not an internal variable. Nothing
in ispell.el changes ispell-dictionary besides the command to help the
user change the preferred dictionary, `ispell-change-dictionary`, so
the value cannot be a remnant from a previous invocation.
Without doing anything, ispell-dictionary being nil signals to ispell.el to
use the spell checker's default, as evident from its Custom type:
(defcustom ispell-dictionary nil
"Default dictionary to use if `ispell-local-dictionary' is nil."
:type '(choice string
(const :tag "default" nil))
:group 'ispell)
In fact, the user can set ispell-dictionary in their init.el when
they're using aspell and have it work as expected. That's why I consider
this a bug.
> Moreover, if you manually set ispell-dictionary, then what would be
> the purpose of calling ispell-find-hunspell-dictionaries at all?
I don't call ispell-find-hunspell-dictionaries myself --- turning on
flyspell eventually calls it.
The error actually occurs when flyspell-mode-on calls
ispell-set-spellchecker-params, which in turn calls
ispell-find-hunspell-dictionaries to set up internal variables.
This is how Chen Bin's workaround works: it sets
ispell-local-dictionary-alist first, then sets
ispell-hunspell-dictionary-alist to it, preventing
ispell-set-spellchecker-params from triggering the error.
ispell-find-hunspell-dictionaries in fact always returns nil, and is
only usedfor side effects: setting up
- ispell-hunspell-dictionary-alist,
- ispell-hunspell-dict-paths-alist,
- and ispell-dicts-name2locale-equivs-alist.
I'd like to hear more perspectives on this as well.