[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend

From: Eli Zaretskii
Subject: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend
Date: Tue, 03 Nov 2020 18:45:02 +0200

> From: Reuben Thomas <rrt@sc3d.org>
> Date: Mon, 2 Nov 2020 21:49:33 +0000
> Cc: dinkonin <dinkonin@gmail.com>, 44318@debbugs.gnu.org
> 1. Simplify ispell-call-process{,-region} by factoring out the macro 
> ispell-with-safe-default-directory.
> 2. I also found that ispell-check-version can be simplified slightly: aspell 
> has accepted -vv since 2004, so use
> it always.
> 3. When spell-checking, collect only standard output. This leaves some 
> spell-checker-specific calls to
> ispell-call-process to collect stderr as well, which as far as I can tell is 
> needed in only one case,
> ispell-find-hunspell-dictionaries; but it doesn't hurt to leave the rest 
> unchanged. I have tested this patch with
> all supported spellcheckers (ispell, aspell, hunspell, enchant).

I'm okay with the first 2, but I'm less comfortable with the 3rd one.
It is wrong to assume that nothing but warnings come through stderr:
for example "hunspell -D" emits the important information to stderr,
at least on my system.  It could be that we don't currently use the 2
functions you suggest to change for such cases, but I think ignoring
stderr in some calls and not the others is a slippery slope of
confusion and subtle bugs.  Since the important case -- that of
enchanty-lsmod -- is already solved, why do we need to make changes
that are not really required, and currently don't give us any gains?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]