bug#32319: 27.0.50; flyspell-mode error on start

[Eli Zaretskii <eliz@gnu.org>]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Cc: 32319@debbugs.gnu.org
> Date: Wed, 01 Aug 2018 12:51:54 -0700
> 
> If the symlink is not present, the "hunspell -D" output looks like:
> 
> SEARCH PATH:.:: <elided>
> AVAILABLE DICTIONARIES
> /usr/share/hunspell/en_TT
> <more>
> Can't open affix or dictionary files for dictionary named "en_US".
> 
> IOW, there's no line that matches "\\.aff$", and
> `hunspell-default-dictionary' is never set, and the error is raised in
> line 1177, where it's assumed that that variable has a value.
> 
> So things go wrong pretty early on, as soon as Hunspell fails to load a
> dictionary.

Does the patch below produce a useful diagnostic?

> What I didn't test was whether having a user option in place, specifying
> a dictionary to use, would prevent even that error from being signaled.
> Mostly because I don't know which option that would be -- I find the
> proliferation of dictionary-holding variables pretty confusing. But I
> suppose the ideal situation would be: having a valid option set would
> swallow the error and allow the process to continue as normal.

AFAIK, with Hunspell we get the default dictionary from Hunspell
itself, not from the user.

Here's the proposed patch, let me know what you think:

diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el
index e77bc7e..321d7dd 100644
--- a/lisp/textmodes/ispell.el
+++ b/lisp/textmodes/ispell.el
@@ -1180,6 +1180,8 @@ ispell-find-hunspell-dictionaries
     ;; Parse and set values for default dictionary.
     (setq hunspell-default-dict (or hunspell-multi-dict
 				    (car hunspell-default-dict)))
+    (or hunspell-default-dict
+        (error "Can't find Hunspell dictionary with an .aff affix file"))
     (setq hunspell-default-dict-entry
 	  (ispell-parse-hunspell-affix-file hunspell-default-dict))
     ;; Create an alist of found dicts with only names, except for default dict.