bug-gnu-emacs
[Top][All Lists]
Advanced

[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 18:27:32 +0000

On Tue, 3 Nov 2020 at 17:32, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 3 Nov 2020 17:19:56 +0000
> Cc: 44318@debbugs.gnu.org, dinkonin <dinkonin@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.)

I'll leave it for now—it doesn't seem to have been a serious problem, and the warnings are only emitted for an incorrectly-installed Enchant, as we observed. I am thinking about a major overhaul/rewrite of Enchant (internal changes only!), so that may be an issue to address then.

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.

I don't understand this: Emacs, to this day, is happy to import large quantities of code from other project; let alone the option of forking/maintaining free software, which is one of its great benefits. And because Enchant has such a similar interface to the other supported spell-checkers, the cost of switching is low. For myself, I'd be more concerned with bugs or missing functionality in Enchant as a reason to be cautious (i.e. I would want to see a phased transition) than about the long-term prospects.

In any case, the principal reason I'm thinking about rewriting Enchant is to make it easier to maintain, so hopefully I'm moving towards making it more palatable in your terms too.

--
https://rrt.sc3d.org

reply via email to

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