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: Tue, 3 Nov 2020 17:19:56 +0000 Message-ID: References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> <83h7q8e8ja.fsf@gnu.org> <838sbjepcw.fsf@gnu.org> <83y2jjd9ix.fsf@gnu.org> <83a6vycru9.fsf@gnu.org> <835z6mcqyg.fsf@gnu.org> Reply-To: Reuben Thomas Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000009186405b33713f1" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6856"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dinkonin , 44318@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 03 18:21:22 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 1kZzzl-0001eS-FZ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Nov 2020 18:21:21 +0100 Original-Received: from localhost ([::1]:45938 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZzzk-0006bV-HF for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Nov 2020 12:21:20 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57052) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kZzzS-0006at-AF for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2020 12:21:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34753) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kZzzR-0005sg-WC for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2020 12:21:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kZzzR-0006UU-Sz for bug-gnu-emacs@gnu.org; Tue, 03 Nov 2020 12:21: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: Tue, 03 Nov 2020 17:21: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.160442401724870 (code B ref 44318); Tue, 03 Nov 2020 17:21:01 +0000 Original-Received: (at 44318) by debbugs.gnu.org; 3 Nov 2020 17:20:17 +0000 Original-Received: from localhost ([127.0.0.1]:46299 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZzyi-0006T4-QO for submit@debbugs.gnu.org; Tue, 03 Nov 2020 12:20:17 -0500 Original-Received: from mail-oi1-f181.google.com ([209.85.167.181]:43070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZzyf-0006So-Fy for 44318@debbugs.gnu.org; Tue, 03 Nov 2020 12:20:15 -0500 Original-Received: by mail-oi1-f181.google.com with SMTP id t143so7545971oif.10 for <44318@debbugs.gnu.org>; Tue, 03 Nov 2020 09:20:13 -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=XocL+Ahp1/TazU9qCpaU6qbDgbLIovx/wffMabIFNEg=; b=c0YVhx6j3jSs6q61MNDJk69J2ZlbWXwIsvAxA0QlRjqzB/HivQYa6qCBGbKTArN5YG KaCJvs1wq1tTOgDdptvPQzlcE4tXWnkRt5utOG5hC63SMgtnIfRLvo6rvYF2xxWFCvWF hz5khXzdC9ND2kbSgzUs4r8jn7iLsl7sap2CE= 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=XocL+Ahp1/TazU9qCpaU6qbDgbLIovx/wffMabIFNEg=; b=DTz4HuN/tW3YAxT4AOuYUQk6AxaxaTtBd2+xF67VAVKR3zqggchVQsfv1rYlvQDCFc E06ONIXeHeqcPBo2VgPI/Iz1qZuGdTJJU+Hgs8bm5FBlfMPnD8GAgmG7Rdun2uO1gXjr L3MLF6WHhU+SseN8m1u01hQUBHqSlimWlmvdldJ6ISst4Y2TwPwTvdQE7jpcWLHCt/1s 2wlUUFOZC5MdHx5x1oQ5I7AryW+70M7/BBcR91KKTjvQVE5fZkZ1Y+njflPU85nNgg/2 26h/fFdx4iinh+MYa4d8agWI995XnuQev79pQdxgfpQPYYLufIILUA+u2fYBy+PFQ34o ib/Q== X-Gm-Message-State: AOAM531KXI4SOdU0E823B2kqR6GcAp0A7F1a0XA+w6BdUuafWQobn2O+ CxGiZWZ5XOunZJJi0L7tD5q1tN7dBhrT3K8WIuFjUg== X-Google-Smtp-Source: ABdhPJzlTDhl3ayETzEKaZYLDXZ2PxR8RKS2adAfYsPmAfQcrhVAMo90vP1B4apVD0OBw4wWMOYeMex0Y2Kq3etf86I= X-Received: by 2002:aca:a9c8:: with SMTP id s191mr112551oie.11.1604424007482; Tue, 03 Nov 2020 09:20:07 -0800 (PST) In-Reply-To: <835z6mcqyg.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:192627 Archived-At: --00000000000009186405b33713f1 Content-Type: text/plain; charset="UTF-8" On Tue, 3 Nov 2020 at 17:04, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Tue, 3 Nov 2020 16:55:13 +0000 > > > > Since the important case -- that of > > enchanty-lsmod -- is already solved, why do we need to make changes > > that are not really required, and currently don't give us any gains? > > > > Unfortunately, as I mentioned before, it's not completely solved, as the > "enchant" program outputs warnings > > on stderr, just like enchant-lsmod. This is interpreted by Emacs as > additions to the suggestions or > > corrections list, which is clearly wrong. > > Then I suggest that you fix that upstream. It is not nice for Enchant > to output stuff to stderr while communicating with a front-end via a > pipe, under the -a switch. It's a violation of the protocol of sorts: > anything you want to say in that mode should be said via stdout. > 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). I admit that Emacs is the only client I know of that uses Enchant (or any of the spellchecker programs we support other than ispell); much of its command-line interface is designed specifically to support Emacs. On the other hand, I can't see a solution to this problem that doesn't involve simply suppressing the warning message altogether, where the user will never see it, including in manual testing. I guess it would be possible only to emit warnings when stderr is a tty, for example, but that seems like a hack; the solution I proposed is at worst a slight tightening of the protocol that is already in agreement with all known implementations, of which ispell is obsolete, aspell is obsolescent, and hunspell is mature: it's unlikely any of them will act differently in future. A longer-term solution would be to drop support for spellcheckers other than Enchant. Enchant supports aspell and hunspell, as well as other spell-checkers not otherwise available to Emacs, including newer, more capable spellcheckers such as nuspell. This would eventually permit the removal of a great deal of code and complexity from ispell.el. -- https://rrt.sc3d.org --00000000000009186405b33713f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 3 Nov 2020 at 17:04, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 3 Nov 2020 16:55:13 +0000
>
>=C2=A0 =C2=A0 Since the important case -- that of
>=C2=A0 enchanty-lsmod -- is already solved, why do we need to make chan= ges
>=C2=A0 that are not really required, and currently don't give us an= y gains?
>
> Unfortunately, as I mentioned before, it's not completely solved, = as the "enchant" program outputs warnings
> on stderr, just like enchant-lsmod. This is interpreted by Emacs as ad= ditions to the suggestions or
> corrections list, which is clearly wrong.

Then I suggest that you fix that upstream.=C2=A0 It is not nice for Enchant=
to output stuff to stderr while communicating with a front-end via a
pipe, under the -a switch.=C2=A0 It's a violation of the protocol of so= rts:
anything you want to say in that mode should be said via stdout.

I'm not sure th= at's right: the warning is emitted at start-up, before enchant starts e= xecuting 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 stream= s (which cannot safely make sense).

I admit that Emacs is the only client I know of that uses Enc= hant (or any of the spellchecker programs we support other than ispell); mu= ch of its command-line interface is designed specifically to support Emacs.= On the other hand, I can't see a solution to this problem that doesn&#= 39;t involve simply suppressing the warning message altogether, where the u= ser will never see it, including in manual testing. I guess it would be pos= sible only to emit warnings when stderr is a tty, for example, but that see= ms like a hack; the solution I proposed is at worst a slight tightening of = the protocol that is already in agreement with all known implementations, o= f which ispell is obsolete, aspell is obsolescent, and hunspell is mature: = it's unlikely any of them will act differently in future.

A longer-term solution would be to = drop support for spellcheckers other than Enchant. Enchant supports aspell = and hunspell, as well as other spell-checkers not otherwise available to Em= acs, including newer, more capable spellcheckers such as nuspell. This woul= d eventually permit the removal of a great deal of code and complexity from= ispell.el.

--
--00000000000009186405b33713f1--