bug#50370: closed (Fix bug in ispell-init-process error handling)

[GNU bug Tracking System]

Your message dated Sun, 05 Sep 2021 10:32:08 +0300
with message-id <837dfvv5on.fsf@gnu.org>
and subject line Re: bug#50370: Fix bug in ispell-init-process error handling
has caused the debbugs.gnu.org bug report #50370,
regarding Fix bug in ispell-init-process error handling
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
50370: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=50370
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: Fix bug in ispell-init-process error handling Date: Fri, 3 Sep 2021 20:53:24 -0700

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

patch
Description: Binary data

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#50370: Fix bug in ispell-init-process error handling
>
>
>
>
> Date: 
>
> Sun, 05 Sep 2021 10:32:08 +0300
>
>
>
>
> > 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.
>
>
> --- End Message ---