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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: dinkonin <at> gmail.com, 44318 <at> debbugs.gnu.org
Subject: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend
Date: Tue, 03 Nov 2020 19:31:57 +0200

> From: Reuben Thomas <rrt <at> sc3d.org>
> Date: Tue, 3 Nov 2020 17:19:56 +0000
> Cc: 44318 <at> debbugs.gnu.org, dinkonin <dinkonin <at> gmail.com>
> 
> 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).

It worked until now.  Enchant is the new kid on the block, so I
respectfully request that it behaves itself.  Yes, it probably means
it should suppress the warning when invoked with -a, but I see no
problem with that.  (You could even consider suppressing the warning
entirely, and only emitting it when some feature which requires the
problematic trait is requested.  But I won't tell you how to develop
Enchant's UI.)

> A longer-term solution would be to drop support for spellcheckers other than Enchant.

I think it would be wrong for Emacs to do that, as that would put all
the eggs in a single basket, something that is not safe in Free
Software world, where packages become unmaintained outside of our
control.  Not having to deal with idiosyncratic behavior of several
spellers is an advantage, but I think the risk of being left without
an actively maintained spell-checking engine is so serious that it
tramps that advantage many times over.

Previous Next

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