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

[Reuben Thomas via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]

On Tue, 3 Nov 2020 at 17:04, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Tue, 3 Nov 2020 16:55:13 +0000
> >
> >    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.
>
> Then I suggest that you fix that upstream.  It is not nice for Enchant
> to output stuff to stderr while communicating with a front-end via a
> pipe, under the -a switch.  It's a violation of the protocol of sorts:
> anything you want to say in that mode should be said via stdout.
>

I'm not sure that's right: the warning is emitted at start-up, before
enchant starts executing the protocol. In any case, as I said before, I
don't think it makes sense for a client of a pipe protocol like this to
combine two streams (which cannot safely make sense).

I admit that Emacs is the only client I know of that uses Enchant (or any
of the spellchecker programs we support other than ispell); much of its
command-line interface is designed specifically to support Emacs. On the
other hand, I can't see a solution to this problem that doesn't involve
simply suppressing the warning message altogether, where the user will
never see it, including in manual testing. I guess it would be possible
only to emit warnings when stderr is a tty, for example, but that seems
like a hack; the solution I proposed is at worst a slight tightening of the
protocol that is already in agreement with all known implementations, of
which ispell is obsolete, aspell is obsolescent, and hunspell is mature:
it's unlikely any of them will act differently in future.

A longer-term solution would be to drop support for spellcheckers other
than Enchant. Enchant supports aspell and hunspell, as well as other
spell-checkers not otherwise available to Emacs, including newer, more
capable spellcheckers such as nuspell. This would eventually permit the
removal of a great deal of code and complexity from ispell.el.

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 3530 bytes --]