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: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dinkonin <dinkonin <at> gmail.com>, 44318 <at> debbugs.gnu.org
Subject: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend
Date: Tue, 3 Nov 2020 18:27:32 +0000

[Message part 1 (text/plain, inline)]

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

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


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

[Message part 2 (text/html, inline)]

Previous Next

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