* bug#50370: Fix bug in ispell-init-process error handling
[not found] <e086ce83-5262-4007-aff3-56fa84427459@Spark>
@ 2021-09-04 3:53 ` Ian W
2021-09-04 12:00 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Ian W @ 2021-09-04 3:53 UTC (permalink / raw)
To: 50370
[-- Attachment #1.1: Type: text/plain, Size: 2019 bytes --]
This fixes the error handling in ispell-init-process. I encountered this bug, and also saw it mentioned here: https://mail.gnu.org/archive/html/auctex/2021-08/msg00007.html
The previous behavior involved the ispell process terminating
prematurely (correct behavior, invalid input) and then calling
ispell-accept-output. Because ispell-process had terminated,
ispell-accept-output threw its own error, which prevented the underlying
error from being displayed.
The bug resulted in the following interaction:
ispell-word would print out:
"Starting new Ispell process aspell with default dictionary...done"
"ispell-accept-output: No Ispell process to read output from!"
The correct behavior is:
"Starting new Ispell process aspell with default dictionary...done"
"cond: Error: ~/.emacs.d/.local/etc/ispell/.pws: The language "nil" is not known. This is probably because: the file "/usr/local/Cellar/aspell/0.60.8/lib/aspell-0.60/nil.dat" can not be opened for reading.""
In GNU Emacs 28.0.50 (build 1, x86_64-apple-darwin20.5.0, NS appkit-2022.50 Version 11.4 (Build 20F71))
of 2021-08-15 built on Ians-MacBook-Pro-2.local
Windowing system distributor 'Apple', version 10.3.2022
System Description: macOS 11.5.2
Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/usr/local/share/emacs/site-lisp
--infodir=/usr/local/Cellar/emacs-plus@28/28.0.50/share/info/emacs
--prefix=/usr/local/Cellar/emacs-plus@28/28.0.50 --with-xml2
--with-gnutls --with-native-compilation --without-dbus
--with-imagemagick --with-modules --with-rsvg --with-xwidgets --with-ns
--disable-ns-self-contained 'CFLAGS=-I/usr/local/opt/gcc/include
-I/usr/local/opt/libgccjit/include -I/usr/local/opt/gmp/include
-I/usr/local/opt/jpeg/include' 'LDFLAGS=-L/usr/local/lib/gcc/11
-I/usr/local/opt/gcc/include -I/usr/local/opt/libgccjit/include
-I/usr/local/opt/gmp/include -I/usr/local/opt/jpeg/include''
The patch is attached.
Ian
[-- Attachment #1.2: Type: text/html, Size: 2633 bytes --]
[-- Attachment #2: patch --]
[-- Type: application/octet-stream, Size: 977 bytes --]
diff --git a/lisp/textmodes/ispell.el b/lisp/textmodes/ispell.el
index c2f6b35df8..ce0653c434 100644
--- a/lisp/textmodes/ispell.el
+++ b/lisp/textmodes/ispell.el
@@ -2923,7 +2923,13 @@ Keeps argument list for future Ispell invocations for no async support."
;; But first wait to see if some more output is going to arrive.
;; Otherwise we get cool errors like "Can't open ".
(sleep-for 1)
- (ispell-accept-output 3)
+ ;; To avoid `ispell-accept-output' throwing it's own
+ ;; error, we check that it will receive from a valid
+ ;; process.
+ (when (if ispell-async-processp
+ (process-live-p ispell-process)
+ ispell-process)
+ (ispell-accept-output 3))
(error "%s" (mapconcat #'identity ispell-filter "\n"))))
(setq ispell-filter nil) ; Discard version ID line
(let ((extended-char-mode (ispell-get-extended-character-mode)))
^ permalink raw reply related [flat|nested] 5+ messages in thread
* bug#50370: Fix bug in ispell-init-process error handling
2021-09-04 3:53 ` bug#50370: Fix bug in ispell-init-process error handling Ian W
@ 2021-09-04 12:00 ` Eli Zaretskii
[not found] ` <dc51f1a1-953c-45e9-90ea-6ca8c0288ed7@Spark>
0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2021-09-04 12:00 UTC (permalink / raw)
To: Ian W; +Cc: 50370
> Date: Fri, 3 Sep 2021 20:53:24 -0700
> From: Ian W <ian@wahbe.com>
>
> This fixes the error handling in ispell-init-process. I encountered this bug, and also saw it mentioned here:
> https://mail.gnu.org/archive/html/auctex/2021-08/msg00007.html
>
> The previous behavior involved the ispell process terminating
> prematurely (correct behavior, invalid input) and then calling
> ispell-accept-output. Because ispell-process had terminated,
> ispell-accept-output threw its own error, which prevented the underlying
> error from being displayed.
>
> The bug resulted in the following interaction:
> ispell-word would print out:
> "Starting new Ispell process aspell with default dictionary...done"
> "ispell-accept-output: No Ispell process to read output from!"
>
> The correct behavior is:
> "Starting new Ispell process aspell with default dictionary...done"
> "cond: Error: ~/.emacs.d/.local/etc/ispell/.pws: The language "nil" is not known. This is probably because: the
> file "/usr/local/Cellar/aspell/0.60.8/lib/aspell-0.60/nil.dat" can not be opened for reading.""
I'm not sure I agree that the "correct behavior" better than the
"incorrect". The error message is not more self-explanatory, at
least.
Anyway, do you have a recipe for reproducing this problem? The URL of
the AUCTeX discussion seems to say it happens every time? I don't
think I understand what's going wrong to trigger the problem.
Thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#50370: Fix bug in ispell-init-process error handling
[not found] ` <dc51f1a1-953c-45e9-90ea-6ca8c0288ed7@Spark>
@ 2021-09-04 18:40 ` Eli Zaretskii
2021-09-04 19:38 ` Ian W
0 siblings, 1 reply; 5+ messages in thread
From: Eli Zaretskii @ 2021-09-04 18:40 UTC (permalink / raw)
To: Ian W; +Cc: 50370
[Please use Reply All to keep the bug address on the CC list.]
> Date: Sat, 4 Sep 2021 11:33:42 -0700
> From: Ian W <ian@wahbe.com>
>
> I think it’s a better error message, but that is just my opinion. It tells me that ispell is trying to read an invalid
> dictionary file. In my case, I deleted that file and everything started working. I also think it’s the error message
> intended to be displayed (by the ispell program and ispell package), as it is the error message designed to
> help the user solve their problem.
>
> (t
> ;; Otherwise, it must be an error message. Show the user.
> ;; But first wait to see if some more output is going to arrive.
> ;; Otherwise we get cool errors like "Can't open ".
> (sleep-for 1)
> (ispell-accept-output 3) ;; <<< This is the line that errors >>>
> (error "%s" (mapconcat #'identity ispell-filter "\n"))))
>
> So the intended error message is never displayed.
>
> I’m sorry for not including a repo. I got it consistently because I had a bad file cached by aspell (or maybe
> doom). You also get the same message when you didn’t install your dictionaries correctly. This is a problem
> in how ispell displays errors, so it’s consistent but only if you already had a real problem with ispell.
>
> To repo:
> (setq ispell-local-dictionary-overridden t
> ispell-local-dictionary "not-a-dict")
>
> This misconfigures your local dictionary, and ensures that the ispell process will error on start. Then run
> ispell-word on any word. Thanks for the prompt response.
With the above recipe, I get:
ispell-phaf: No matching entry for not-a-dict in ‘ispell-hunspell-dict-paths-alist’.
(My speller is Hunspell.)
So does this mean this problem doesn't happen with Hunspell? Ir is
the recipe incomplete or something?
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#50370: Fix bug in ispell-init-process error handling
2021-09-04 18:40 ` Eli Zaretskii
@ 2021-09-04 19:38 ` Ian W
2021-09-05 7:32 ` Eli Zaretskii
0 siblings, 1 reply; 5+ messages in thread
From: Ian W @ 2021-09-04 19:38 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 50370
[-- Attachment #1: Type: text/plain, Size: 2865 bytes --]
I think that hunspell is different. It validates that the dictionary really exists in the beginning of ispell-start-process:
(defun ispell-start-process ()
"Start the Ispell process, with support for no asynchronous processes.
Keeps argument list for future Ispell invocations for no async support."
;; `ispell-current-dictionary' and `ispell-current-personal-dictionary'
;; are properly set in `ispell-internal-change-dictionary'.
;; Parse hunspell affix file if using hunspell and entry is uninitialized.
(if ispell-really-hunspell
(or (cadr (assoc ispell-current-dictionary ispell-dictionary-alist))
(ispell-hunspell-fill-dictionary-entry ispell-current-dictionary)))
…)
Having seen this, I think that this will only be a problem for ispell and aspell. I just tested the recipe and it works on “emacs -Q” (I have ispell installed correctly, and emacs defaults to that).
On Sep 4, 2021, 11:40 AM -0700, Eli Zaretskii <eliz@gnu.org>, wrote:
> [Please use Reply All to keep the bug address on the CC list.]
>
> > Date: Sat, 4 Sep 2021 11:33:42 -0700
> > From: Ian W <ian@wahbe.com>
> >
> > I think it’s a better error message, but that is just my opinion. It tells me that ispell is trying to read an invalid
> > dictionary file. In my case, I deleted that file and everything started working. I also think it’s the error message
> > intended to be displayed (by the ispell program and ispell package), as it is the error message designed to
> > help the user solve their problem.
> >
> > (t
> > ;; Otherwise, it must be an error message. Show the user.
> > ;; But first wait to see if some more output is going to arrive.
> > ;; Otherwise we get cool errors like "Can't open ".
> > (sleep-for 1)
> > (ispell-accept-output 3) ;; <<< This is the line that errors >>>
> > (error "%s" (mapconcat #'identity ispell-filter "\n"))))
> >
> > So the intended error message is never displayed.
> >
> > I’m sorry for not including a repo. I got it consistently because I had a bad file cached by aspell (or maybe
> > doom). You also get the same message when you didn’t install your dictionaries correctly. This is a problem
> > in how ispell displays errors, so it’s consistent but only if you already had a real problem with ispell.
> >
> > To repo:
> > (setq ispell-local-dictionary-overridden t
> > ispell-local-dictionary "not-a-dict")
> >
> > This misconfigures your local dictionary, and ensures that the ispell process will error on start. Then run
> > ispell-word on any word. Thanks for the prompt response.
>
> With the above recipe, I get:
>
> ispell-phaf: No matching entry for not-a-dict in ‘ispell-hunspell-dict-paths-alist’.
>
> (My speller is Hunspell.)
>
> So does this mean this problem doesn't happen with Hunspell? Ir is
> the recipe incomplete or something?
[-- Attachment #2: Type: text/html, Size: 3546 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#50370: Fix bug in ispell-init-process error handling
2021-09-04 19:38 ` Ian W
@ 2021-09-05 7:32 ` Eli Zaretskii
0 siblings, 0 replies; 5+ messages in thread
From: Eli Zaretskii @ 2021-09-05 7:32 UTC (permalink / raw)
To: Ian W; +Cc: 50370-done
> Date: Sat, 4 Sep 2021 12:38:40 -0700
> From: Ian W <ian@wahbe.com>
> Cc: 50370@debbugs.gnu.org
>
> I think that hunspell is different. It validates that the dictionary really exists in the beginning of
> ispell-start-process:
>
> (defun ispell-start-process ()
> "Start the Ispell process, with support for no asynchronous processes.
> Keeps argument list for future Ispell invocations for no async support."
> ;; `ispell-current-dictionary' and `ispell-current-personal-dictionary'
> ;; are properly set in `ispell-internal-change-dictionary'.
>
> ;; Parse hunspell affix file if using hunspell and entry is uninitialized.
> (if ispell-really-hunspell
> (or (cadr (assoc ispell-current-dictionary ispell-dictionary-alist))
> (ispell-hunspell-fill-dictionary-entry ispell-current-dictionary)))
> …)
>
> Having seen this, I think that this will only be a problem for ispell and aspell. I just tested the recipe and it
> works on “emacs -Q” (I have ispell installed correctly, and emacs defaults to that).
Thanks, I installed the change, and I'm therefore closing this bug.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-09-05 7:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <e086ce83-5262-4007-aff3-56fa84427459@Spark>
2021-09-04 3:53 ` bug#50370: Fix bug in ispell-init-process error handling Ian W
2021-09-04 12:00 ` Eli Zaretskii
[not found] ` <dc51f1a1-953c-45e9-90ea-6ca8c0288ed7@Spark>
2021-09-04 18:40 ` Eli Zaretskii
2021-09-04 19:38 ` Ian W
2021-09-05 7:32 ` Eli Zaretskii
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.