GNU bug report logs - #49982
27.2; ispell.el fails to find a Hunspell dictionary to use as default despite ispell-dictionary being set

Previous Next

Full log

View this message in rfc822 format

From: Kisaragi Hiu <mail <at> kisaragi-hiu.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 49982 <at> 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 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.