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: 44318 <at> debbugs.gnu.org, dinkonin <dinkonin <at> gmail.com>
Subject: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend
Date: Mon, 2 Nov 2020 15:49:19 +0000

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

On Mon, 2 Nov 2020 at 15:43, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Reuben Thomas <rrt <at> sc3d.org>
> > Date: Mon, 2 Nov 2020 08:35:13 +0000
> > Cc: dinkonin <dinkonin <at> gmail.com>, 44318 <at> debbugs.gnu.org
> >
> > I believe that the ispell.el code (which I wrote) is buggy: it should
> not be incorporating warnings into its
> > output.
> >
> > Also, the patch I offered is a simplification of the original code. So,
> I don't think we are losing here.
> >
> > Eli, I quite agree with your sentiment, and I would certainly not
> advocate installing a workaround in Emacs
> > unless there were compelling reasons. However, I do not see this as a
> workaround, and as it is also a
> > simplification, I don't see a problem.
>
> I have a problem with ignoring stderr because it can provide some
> useful information.


It is not so much a question of ignoring stderr (for example, this output
could be shown to the Emacs user), it is a question of not treating it as
part of the output of enchant-lsmod.


> Moreover, no one said that some client of Enchant, current or future,
> won't decide to produce non-error output on stderr.
>

I'm not sure what you mean here. "enchant-lsmod" simply queries its own
providers (spelling back-ends). I maintain all the code involved (there are
currently no third-party providers for Enchant that I'm aware of), and, for
what it's worth, decide how it should work.

In this case, the providers should not be outputting anything, either to
stderr or stdout, and indeed, they do not. It is enchant-lsmod that emits
the warning when it cannot load a provider. This is a legitimate warning,
but it does not form part of its output.

So I, as upstream maintainer, am telling you that indeed, it is not correct
that Emacs should take enchant-lsmod's stderr as part of its output! (As I
said above, it would be possible to capture stderr separately and display
it to the user, though I don't recommend that currently, because the
warnings are not written for users. Other programs that use Enchant do not
show these warnings, they simply omit providers that do not load from the
list of languages/spelling checkers that are available.)

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