--- Begin Message ---
|
Subject: |
27.0.50; flyspell-mode error on start |
|
Date: |
Mon, 30 Jul 2018 12:42:24 -0700 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Turning on flyspell-mode started giving me an error a few days ago, on
two different machines I use. Both are Arch linux, both running Emacs
master.
My only ispell customizations:
(setq ispell-program-name (executable-find "hunspell"))
(setq ispell-personal-dictionary "~/.aspell.en_US.pws")
Starting flyspell-mode gives me:
Debugger entered--Lisp error: (wrong-type-argument stringp nil)
string-match("," nil 0)
split-string(nil "," t)
ispell-parse-hunspell-affix-file(nil)
ispell-hunspell-fill-dictionary-entry(nil)
ispell-start-process()
ispell-init-process()
ispell-buffer-local-words()
ispell-accept-buffer-local-defs()
flyspell-accept-buffer-local-defs(force)
flyspell-mode-on()
>From "emacs -Q", setting `ispell-program-name' to (executable-find
"hunspell") (the first line of my customizations above) is sufficient to
trigger the error.
`ispell-current-dictionary' seems to be nil during the whole process,
which causes the eventual error.
The Hunspell version on Arch is "1.6.2", which is the value of
`ispell-really-hunspell'.
Hope that's enough information!
In GNU Emacs 27.0.50 (build 37, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2018-07-30 built on clem
Repository revision: 63ef79329935b790b9c8107125bce66e1f272c2e
Windowing system distributor 'The X.Org Foundation', version 11.0.12000000
System Description: Arch Linux
Recent messages:
Entering debugger...
Debug on Error disabled globally
Mark set
Mark activated
Back to top level
Mark set
Quit [2 times]
Mark saved where search started
"/usr/bin/hunspell"
"1.6.2"
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#32319: 27.0.50; flyspell-mode error on start |
|
Date: |
Sat, 11 Aug 2018 10:36:14 +0300 |
> From: Eric Abrahamsen <address@hidden>
> Cc: address@hidden
> Date: Sat, 04 Aug 2018 22:21:47 -0700
>
> > Does the patch below produce a useful diagnostic?
>
> This patch is just fine, and would certainly be a lot better than the
> current situation. I only note that, if we allow this function to fail
> silently, the error you get *later on*, when you try to use flyspell to
> do something, comes directly from hunspell and says exactly what the
> problem is (ie, which dictionary it tried and failed to load). That's
> even more helpful. If we did that, this function could just call
> `ispell-print-if-debug' and log the failure quietly.
>
> But raising an error directly is also fine, and might be preferable in
> order to avoid creating weird problems further down the line.
OK, so I installed my patch on the master branch, and I'm marking this
bug done. Thanks for the analysis and the feedback.
--- End Message ---