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