From: Kisaragi Hiu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 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 03:51:22 +0900 [thread overview]
Message-ID: <54d5e013-aeff-ef7b-ad9e-e4c8dfa72d37@kisaragi-hiu.com> (raw)
In-Reply-To: <83h7fxfft0.fsf@gnu.org>
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.
next prev parent reply other threads:[~2021-08-10 18:51 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-10 15:12 bug#49982: 27.2; ispell.el fails to find a Hunspell dictionary to use as default despite ispell-dictionary being set Kisaragi Hiu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-10 16:03 ` Eli Zaretskii
2021-08-10 18:51 ` Kisaragi Hiu via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54d5e013-aeff-ef7b-ad9e-e4c8dfa72d37@kisaragi-hiu.com \
--to=bug-gnu-emacs@gnu.org \
--cc=49982@debbugs.gnu.org \
--cc=eliz@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 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).