[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:19:56 +0000

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.


reply via email to

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