[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: Reuben Thomas
Subject: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend
Date: Tue, 3 Nov 2020 17:06:30 +0000

[Apologies Eli, re-sending to list rather than just you.]

On Tue, 3 Nov 2020 at 16:45, Eli Zaretskii <eliz@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.


reply via email to

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