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.
patch