GNU bug report logs - #44318
28.0.50; Problem with ispell/flyspell and ""enchant"" backend

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 44318 <at> debbugs.gnu.org, dinkonin <at> gmail.com
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 <at> sc3d.org>
> Date: Mon, 2 Nov 2020 21:49:33 +0000
> Cc: dinkonin <dinkonin <at> gmail.com>, 44318 <at> 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?

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.