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

[Eli Zaretskii <eliz@gnu.org>]

> From: Kisaragi Hiu <mail@kisaragi-hiu.com>
> Cc: 49982@debbugs.gnu.org
> Date: Wed, 11 Aug 2021 20:17:20 +0900
> 
>  > Indeed, defining DICTIONARY in the environment is the way to control
> the default dictionary.  It is documented in the Hunspell's man page.
> Why cannot it be the solution for when no Hunspell dictionary could be
> found that matches the locale?  Using $DICTIONARY should solve your
> problem both inside Emacs and outside it.
> 
> I don't know, maybe I'm biased here. Hunspell has its quirks, but isn't 
> it ispell.el's job to work around quirks in spellcheckers, and not the 
> end user's?

Not when the spell-checker is basically not configured correctly.

> ispell.el worked around Hunspell 1.7's new output quirk.

That was something users could do nothing on their end to solve.

> Using environment variables to configure subprocesses is always 
> something that a user can do, but, as you know, there's a reason why 
> ispell.el exposes spellchecker options through Emacs user options.

That's not what I meant.  I meant to suggest that you set DICTIONARY
in the init files of your interactive shell, so that it would allow
you to use Hunspell both inside Emacs (because Emacs inherits the
environment variables of its parent shell) and outside Emacs.  I
didn't mean to suggest that you (or others) should inject DICTIONARY
into the environment of the Hunspell sub-process by doing something in
Emacs, like setenv etc.

> Besides, which dictionary one specifies in `DICTIONARY` doesn't actually 
> matter, it just needs to be one that exists, as it will be overridden by 
> ispell-dictionary when ispell.el actually starts spellchecking.

It should be the dictionary you want to use by default.  In your case,
I assume it's en_US.