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

Previous Next

Package: emacs;

Reported by: dinkonin <dinkonin <at> gmail.com>

Date: Thu, 29 Oct 2020 21:41:02 UTC

Severity: normal

Found in version 28.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44318 <at> debbugs.gnu.org, dinkonin <dinkonin <at> gmail.com>
Subject: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend
Date: Tue, 3 Nov 2020 17:06:30 +0000
[Message part 1 (text/plain, inline)]
[Apologies Eli, re-sending to list rather than just you.]

On Tue, 3 Nov 2020 at 16:45, Eli Zaretskii <eliz <at> gnu.org> wrote:

>
> I'm okay with the first 2,


Great, I'll install those!

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.


Exactly, I found this while testing a more ambitious patch that never
collected stderr (and indeed versions of Enchant until last night's release
of 2.2.13 printed their --version output on stderr).

Hence, all of those uses still collect stderr.

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.


The two functions I changed implement a long-running communication with the
spellchecker using the ispell protocol, notionally over a pipe. There's no
reason to mix two streams, and in any case that would only work
fortuitously, since the spellchecker doesn't know how those streams will be
combined. In other words, a source of confusion and subtle bugs.

Fortunately, none of the current spellcheckers we support tries to do this.


>   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?
>

Unfortunately, as I mentioned before, it's not completely solved, as the
"enchant" program outputs warnings on stderr, just like enchant-lsmod. This
is interpreted by Emacs as additions to the suggestions or corrections
list, which is clearly wrong.

-- 
https://rrt.sc3d.org
[Message part 2 (text/html, inline)]

This bug report was last modified 4 years and 293 days ago.

Previous Next


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