From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Reuben Thomas via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend Date: Mon, 2 Nov 2020 15:49:19 +0000 Message-ID: References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> <83h7q8e8ja.fsf@gnu.org> <838sbjepcw.fsf@gnu.org> Reply-To: Reuben Thomas Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000001e53b605b321b1e0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8275"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44318@debbugs.gnu.org, dinkonin To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Nov 02 16:52:13 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kZc7w-00022W-Ld for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 Nov 2020 16:52:12 +0100 Original-Received: from localhost ([::1]:38234 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZc7v-0007jR-Ln for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 Nov 2020 10:52:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60304) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZc5q-00058G-4x for bug-gnu-emacs@gnu.org; Mon, 02 Nov 2020 10:50:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58924) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZc5p-0003HV-PN for bug-gnu-emacs@gnu.org; Mon, 02 Nov 2020 10:50:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kZc5p-0005eT-Nl for bug-gnu-emacs@gnu.org; Mon, 02 Nov 2020 10:50:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Nov 2020 15:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44318 X-GNU-PR-Package: emacs Original-Received: via spool by 44318-submit@debbugs.gnu.org id=B44318.160433218021666 (code B ref 44318); Mon, 02 Nov 2020 15:50:01 +0000 Original-Received: (at 44318) by debbugs.gnu.org; 2 Nov 2020 15:49:40 +0000 Original-Received: from localhost ([127.0.0.1]:42231 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZc5T-0005dI-Rd for submit@debbugs.gnu.org; Mon, 02 Nov 2020 10:49:40 -0500 Original-Received: from mail-oo1-f48.google.com ([209.85.161.48]:38305) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZc5Q-0005d0-6Y for 44318@debbugs.gnu.org; Mon, 02 Nov 2020 10:49:36 -0500 Original-Received: by mail-oo1-f48.google.com with SMTP id v123so3456909ooa.5 for <44318@debbugs.gnu.org>; Mon, 02 Nov 2020 07:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ew7T5JQy9vHg0/dKmLTEySgH3LIXAUTHgxEoPEORtm4=; b=0VwJsQVF0TIKGIK08pdg2xm2h2b94U1tMTVpHJxfm5l/ASKYGcUo4B79JxhwwEajGx Dt6m2zooxG6Kg5/jpCwBKJGdJbGxKI0Peie5d0ITp0pKrRXKiniD+2ri2Ax32KbHxdOv Nwe3llhUf2H0KFfX3tNxo5gxRFRioPFf8ToIU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ew7T5JQy9vHg0/dKmLTEySgH3LIXAUTHgxEoPEORtm4=; b=TarmSUlPqIcVRQ0atP1x0f0yuGbNh9Qy3ZMP0lqkIpKGvMqR0J2bVIRpCjzdcRKRHw q0+SDVUNMMYBXFC0+xr3zsGAzGkTIc0p1znjt6uNtW9nt8r/RSa/OaQWj0vupnk4v5mw Xq4QEndFqaaPh0CCErFWvdhV2CVlAeE23B5G3rN/CZG9UbDFtQWUAnKJOy99XcXqrqrE JnL7jc7OIoCp04eVBYwf3gNlOPE2hYJofGps1XNmvEdLj7D8NvzOKsEr4uROCDauZcZa WKXvE1ElH7cCLpf6iTgEeoLSn/kgDfp4j6T9RlVdz0CPtnnVOI5/SsJe2uBq3Y2ziNEJ mzcA== X-Gm-Message-State: AOAM530rILwX94gakeTI/qRRgJwFBO5VVGx5ZG+lHr9Z+2RcFnR2nR4K KJS/su5WbnPNHXGoGfQPfaXIOCVkuLUWb1dALF2u6Q== X-Google-Smtp-Source: ABdhPJyfwFyzHZ3NdlOIHWKJ/2GfS1E/udr88OKd+kRx8sa6vR9ei6WI4eJC5Z0aX79HAADt13xf6colRiBIOdIGbek= X-Received: by 2002:a4a:96b0:: with SMTP id s45mr12458064ooi.33.1604332170390; Mon, 02 Nov 2020 07:49:30 -0800 (PST) In-Reply-To: <838sbjepcw.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:192536 Archived-At: --0000000000001e53b605b321b1e0 Content-Type: text/plain; charset="UTF-8" On Mon, 2 Nov 2020 at 15:43, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Mon, 2 Nov 2020 08:35:13 +0000 > > Cc: dinkonin , 44318@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 --0000000000001e53b605b321b1e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 2 Nov 2020 at 15:43, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Mon, 2 Nov 2020 08:35:13 +0000
> Cc: dinkonin <dinkonin@gmail.com>, 44318@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 advo= cate 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 i= s 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 o= f the output of enchant-lsmod.
=C2=A0
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 su= re what you mean here. "enchant-lsmod" simply queries its own pro= viders (spelling back-ends). I maintain all the code involved (there are cu= rrently no third-party providers for Enchant that I'm aware of), and, f= or what it's worth, decide how it should work.
=
In this case, the providers should not be outp= utting 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, a= m 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 po= ssible to capture stderr separately and display it to the user, though I do= n't recommend that currently, because the warnings are not written for = users. Other programs that use Enchant do not show these warnings, they sim= ply omit providers that do not load from the list of languages/spelling che= ckers that are available.)

--
--0000000000001e53b605b321b1e0--