From debbugs-submit-bounces@debbugs.gnu.org Thu Oct 29 17:40:29 2020 Received: (at submit) by debbugs.gnu.org; 29 Oct 2020 21:40:29 +0000 Received: from localhost ([127.0.0.1]:55178 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYFem-0004OW-T3 for submit@debbugs.gnu.org; Thu, 29 Oct 2020 17:40:29 -0400 Received: from lists.gnu.org ([209.51.188.17]:44722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYEUo-0006hM-L3 for submit@debbugs.gnu.org; Thu, 29 Oct 2020 16:26:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51536) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYEUn-000112-6C for bug-gnu-emacs@gnu.org; Thu, 29 Oct 2020 16:26:06 -0400 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]:40987) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kYEUj-0003BH-4V for bug-gnu-emacs@gnu.org; Thu, 29 Oct 2020 16:26:04 -0400 Received: by mail-ed1-x531.google.com with SMTP id l24so4375264edj.8 for ; Thu, 29 Oct 2020 13:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3Jk2myrwBhuvklYxpzVbXTB+cer38vI4VBl+36Eepq0=; b=AYUwx6gFnN/nhlwzoZsBVJip148QgerGyUq1460V0BTaJroyf49ILalPBVXcYeXeIG WJ7YLsTxmzqynJBmE1+pErPFWey1wHueMG0UcjeHMzquh1E0EXvGRbBSsgTJgOq/AZC2 B0aGKcA8e9qGnV5tzZos5V4I0NYxdsmQKh+ohS6BGIAQRQrxB+DT9QiIpVaEqmBTG51i U/dhiG3hG2Ak/todUtuva5IE9TtuChfY4dJolyt4uqkdgGeU4l5nWRa9caX7n5lMLk3U SdbRAkOIoNwir6s4FiXOBb0T9k+FYvhMPsth29KhINhJY0wmbZzOLVRVExujbT0EOLJ1 1Nww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3Jk2myrwBhuvklYxpzVbXTB+cer38vI4VBl+36Eepq0=; b=GJfVCZ9W5eb7pca4oByqBErTr51chV1mS7FsF4qDRcL24QcV6eXycctxudh5vO0xIJ w/2nmUXuxT/Md7Z6y1lZXaZdm+WU5L2sOCyXisCFZBWeJVwZuIgdMXCUuAQZbT942Kg1 BZ6/3hBwoMBD6s9wztJ25/WmnmorzmGvPoD8YxG7GxalZi8BXDGquKjMfrKaaK4RHgDE 2vBKSu3iKRk0Fj5/AxNTSUdwVkQrGgr4ujaAkiKq6a3UvAEyPmp1xRPiJYdi1U0bWKMH dtbNhx4PtUS17p3fPnMoUEM2GoJwHIv1dXPnuis2Wj0RUEui3ReAfJPSVjkaFK4GPYt3 Yo3g== X-Gm-Message-State: AOAM5304YHjSdCXLDm8l2c0RmezEk0FLIQsqMQP01EjUNbf86oFivHnI fbzUvFtAqHiaEF5oOZ98lSgOPsFpL7s6kc47XTWBgktJMmt2 X-Google-Smtp-Source: ABdhPJwAfH7jZxfulavFof8/VKIu4T85XsvQIXErko8AQna9KRzC/YbpTMrVYD9jg2xBgn/tO+OtYhGNpdkaKdrJdOk= X-Received: by 2002:a50:f307:: with SMTP id p7mr5849881edm.235.1604003158182; Thu, 29 Oct 2020 13:25:58 -0700 (PDT) MIME-Version: 1.0 From: dinkonin Date: Thu, 29 Oct 2020 22:25:47 +0200 Message-ID: Subject: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000764ec805b2d516f3" Received-SPF: pass client-ip=2a00:1450:4864:20::531; envelope-from=dinkonin@gmail.com; helo=mail-ed1-x531.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, WEIRD_QUOTING=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 29 Oct 2020 17:40:27 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000764ec805b2d516f3 Content-Type: text/plain; charset="UTF-8" Hello, I'm having some trouble with flyspell using the enchant backend (setq ispell-program-name "enchant-2"). I have installed the latest enchant 2.2.12, without the optional finish and hebrew backends. Flyspell refuses to work with the above setting (no errors just does not detect anything ). Ive narrowed it down to this: when flyspell loads it adds the following line n top of "ispell-enchant-dictionary-alist" ((nil "[[:alpha:]]" "[^[:alpha:]]" "[\n** (process:98935): WARNING **: 22:05:56.283: Error loading plugin: libvoikko.so.1: cannot open shared object file: No such file or directory\n\n\n** (process:98935): WARNING **: 22:05:56.286: Error loading plugin: libhspell.so.0: cannot open shared object file: No such file or directory\n\n0123456789]" t nil nil utf-8) The problem disappears when I manually do: (setq ispell-enchant-dictionary-alist '(("bg_BG" "[[:alpha:]]" "[^[:alpha:]]" "" t nil nil utf-8) ("en_US" "[[:alpha:]]" "[^[:alpha:]]" "" t nil nil utf-8))) I've noticed that enchant-lsmod-2 also produces this error in the terminal, maybe STDERR should be omitted when generating ispell-enchant-dictionary-alist or shoud this be reported upstream to enchant ? In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17.3) of 2020-10-21 built on srv Repository revision: 3be93390fb6680d1e0c3256af72c86635a9eb327 Repository branch: makepkg Windowing system distributor 'The X.Org Foundation', version 11.0.12009000 System Description: Arch Linux Configured using: 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man --with-gameuser=:games --with-sound=alsa --with-modules --without-gconf --without-gsettings --with-nativecomp --with-x-toolkit=gtk3 --without-xaw3d --without-m17n-flt --with-cairo --without-compress-install 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -g -fuse-ld=gold -g -fuse-ld=gold' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now' Configured features: XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GLIB NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES NATIVE_COMP THREADS LIBSYSTEMD JSON PDUMPER LCMS2 Important settings: value of $LC_COLLATE: bg_BG.UTF-8 value of $LC_MONETARY: bg_BG.UTF-8 value of $LC_NUMERIC: bg_BG.UTF-8 value of $LC_TIME: bg_BG.UTF-8 value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Org Minor modes in effect: auto-dim-other-buffers-mode: t persistent-scratch-autosave-mode: t reverse-im-mode: t auto-insert-mode: t yas-global-mode: t yas-minor-mode: t flycheck-inline-mode: t global-flycheck-mode: t flycheck-mode: t buffer-face-mode: t org-indent-mode: t company-box-mode: t amx-mode: t diredfl-global-mode: t treemacs-icons-dired-mode: t treemacs-tag-follow-mode: t treemacs-filewatch-mode: t treemacs-git-mode: deferred treemacs-fringe-indicator-mode: t gcmh-mode: t global-diff-hl-mode: t diff-hl-mode: t global-auto-revert-mode: t global-evil-collection-unimpaired-mode: t evil-collection-unimpaired-mode: t electric-pair-mode: t show-paren-mode: t savehist-mode: t global-company-mode: t company-mode: t evil-org-mode: t save-place-mode: t which-key-mode: t evil-goggles-mode: t evil-lion-mode: t global-evil-surround-mode: t evil-surround-mode: t shell-dirtrack-mode: t evil-mode: t evil-local-mode: t ivy-posframe-mode: t override-global-mode: t all-the-icons-ivy-rich-mode: t ivy-rich-mode: t ivy-mode: t minions-mode: t delete-selection-mode: t general-override-mode: t straight-use-package-mode: t straight-package-neutering-mode: t straight-live-modifications-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t --000000000000764ec805b2d516f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
I'm having some trouble with flyspell using = the enchant backend
(setq ispell-program-name "enchant-2").
I have installed the latest enchant 2.2.12, without the
optional fi= nish and hebrew backends. Flyspell refuses to work with the
above settin= g (no errors just does not detect anything ). Ive
narrowed it down to th= is:

when flyspell loads it adds the following line n top of "is= pell-enchant-dictionary-alist"

((nil "[[:alpha:]]" &q= uot;[^[:alpha:]]" "[\n** (process:98935): WARNING **:
22:05:56= .283: Error loading plugin: libvoikko.so.1: cannot open shared
object fi= le: No such file or directory\n\n\n** (process:98935): WARNING
**: 22:05= :56.286: Error loading plugin: libhspell.so.0: cannot open
shared object= file: No such file or directory\n\n0123456789]" t nil nil
utf-8)
The problem disappears when I manually do:
(setq ispell-enchant-di= ctionary-alist
=C2=A0 =C2=A0 =C2=A0 '(("bg_BG" "[[:al= pha:]]" "[^[:alpha:]]" "" t nil nil utf-8)
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 ("en_US" "[[:alpha:]]" "[= ^[:alpha:]]" "" t nil nil utf-8)))
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
I've noticed th= at enchant-lsmod-2 also produces this error in the
terminal, maybe STDER= R should be omitted when generating
ispell-enchant-dictionary-alist or s= houd this be reported upstream to
enchant ?


In GNU Emacs 28.0= .50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.17= .3)
=C2=A0of 2020-10-21 built on srv
Repository revision: 3be93390fb6= 680d1e0c3256af72c86635a9eb327
Repository branch: makepkg
Windowing sy= stem distributor 'The X.Org Foundation', version 11.0.12009000
S= ystem Description: Arch Linux

Configured using:
=C2=A0'config= ure --prefix=3D/usr --sysconfdir=3D/etc --libexecdir=3D/usr/lib
=C2=A0--= localstatedir=3D/var --mandir=3D/usr/share/man --with-gameuser=3D:games
= =C2=A0--with-sound=3Dalsa --with-modules --without-gconf --without-gsetting= s
=C2=A0--with-nativecomp --with-x-toolkit=3Dgtk3 --without-xaw3d
=C2= =A0--without-m17n-flt --with-cairo --without-compress-install
=C2=A0'= ;CFLAGS=3D-march=3Dx86-64 -mtune=3Dgeneric -O2 -pipe -fno-plt -g
=C2=A0-= fuse-ld=3Dgold -g -fuse-ld=3Dgold' CPPFLAGS=3D-D_FORTIFY_SOURCE=3D2
= =C2=A0LDFLAGS=3D-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
<= br>Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS = GLIB NOTIFY INOTIFY ACL
GNUTLS LIBXML2 FREETYPE HARFBUZZ LIBOTF ZLIB TOO= LKIT_SCROLL_BARS GTK3
X11 XDBE XIM MODULES NATIVE_COMP THREADS LIBSYSTEM= D JSON PDUMPER LCMS2

Important settings:
=C2=A0 value of $LC_COLL= ATE: bg_BG.UTF-8
=C2=A0 value of $LC_MONETARY: bg_BG.UTF-8
=C2=A0 val= ue of $LC_NUMERIC: bg_BG.UTF-8
=C2=A0 value of $LC_TIME: bg_BG.UTF-8
= =C2=A0 value of $LANG: en_US.UTF-8
=C2=A0 locale-coding-system: utf-8-un= ix

Major mode: Org

Minor modes in effect:
=C2=A0 auto-dim-= other-buffers-mode: t
=C2=A0 persistent-scratch-autosave-mode: t
=C2= =A0 reverse-im-mode: t
=C2=A0 auto-insert-mode: t
=C2=A0 yas-global-m= ode: t
=C2=A0 yas-minor-mode: t
=C2=A0 flycheck-inline-mode: t
=C2= =A0 global-flycheck-mode: t
=C2=A0 flycheck-mode: t
=C2=A0 buffer-fac= e-mode: t
=C2=A0 org-indent-mode: t
=C2=A0 company-box-mode: t
=C2= =A0 amx-mode: t
=C2=A0 diredfl-global-mode: t
=C2=A0 treemacs-icons-d= ired-mode: t
=C2=A0 treemacs-tag-follow-mode: t
=C2=A0 treemacs-filew= atch-mode: t
=C2=A0 treemacs-git-mode: deferred
=C2=A0 treemacs-fring= e-indicator-mode: t
=C2=A0 gcmh-mode: t
=C2=A0 global-diff-hl-mode: t=
=C2=A0 diff-hl-mode: t
=C2=A0 global-auto-revert-mode: t
=C2=A0 g= lobal-evil-collection-unimpaired-mode: t
=C2=A0 evil-collection-unimpair= ed-mode: t
=C2=A0 electric-pair-mode: t
=C2=A0 show-paren-mode: t
= =C2=A0 savehist-mode: t
=C2=A0 global-company-mode: t
=C2=A0 company-= mode: t
=C2=A0 evil-org-mode: t
=C2=A0 save-place-mode: t
=C2=A0 w= hich-key-mode: t
=C2=A0 evil-goggles-mode: t
=C2=A0 evil-lion-mode: t=
=C2=A0 global-evil-surround-mode: t
=C2=A0 evil-surround-mode: t
= =C2=A0 shell-dirtrack-mode: t
=C2=A0 evil-mode: t
=C2=A0 evil-local-m= ode: t
=C2=A0 ivy-posframe-mode: t
=C2=A0 override-global-mode: t
= =C2=A0 all-the-icons-ivy-rich-mode: t
=C2=A0 ivy-rich-mode: t
=C2=A0 = ivy-mode: t
=C2=A0 minions-mode: t
=C2=A0 delete-selection-mode: t=C2=A0 general-override-mode: t
=C2=A0 straight-use-package-mode: t
= =C2=A0 straight-package-neutering-mode: t
=C2=A0 straight-live-modificat= ions-mode: t
=C2=A0 tooltip-mode: t
=C2=A0 global-eldoc-mode: t
= =C2=A0 electric-indent-mode: t
=C2=A0 mouse-wheel-mode: t
=C2=A0 tool= -bar-mode: t
=C2=A0 menu-bar-mode: t
=C2=A0 file-name-shadow-mode: t<= br>=C2=A0 global-font-lock-mode: t
=C2=A0 font-lock-mode: t
=C2=A0 bl= ink-cursor-mode: t
=C2=A0 auto-composition-mode: t
=C2=A0 auto-encryp= tion-mode: t
=C2=A0 auto-compression-mode: t
=C2=A0 line-number-mode:= t
=C2=A0 transient-mark-mode: t
--000000000000764ec805b2d516f3-- From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 30 03:38:54 2020 Received: (at 44318) by debbugs.gnu.org; 30 Oct 2020 07:38:54 +0000 Received: from localhost ([127.0.0.1]:55948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYOzu-0007AZ-Bf for submit@debbugs.gnu.org; Fri, 30 Oct 2020 03:38:54 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37296) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYOzt-0007AN-FP for 44318@debbugs.gnu.org; Fri, 30 Oct 2020 03:38:53 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56026) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYOzn-0007CQ-FW; Fri, 30 Oct 2020 03:38:47 -0400 Received: from [176.228.60.248] (port=3816 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kYOzm-0004OQ-UU; Fri, 30 Oct 2020 03:38:47 -0400 Date: Fri, 30 Oct 2020 09:38:28 +0200 Message-Id: <83k0v8b1u3.fsf@gnu.org> From: Eli Zaretskii To: dinkonin , Reuben Thomas In-Reply-To: (message from dinkonin on Thu, 29 Oct 2020 22:25:47 +0200) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: dinkonin > Date: Thu, 29 Oct 2020 22:25:47 +0200 > > I'm having some trouble with flyspell using the enchant backend > (setq ispell-program-name "enchant-2"). > > I have installed the latest enchant 2.2.12, without the > optional finish and hebrew backends. Flyspell refuses to work with the > above setting (no errors just does not detect anything ). Ive > narrowed it down to this: > > when flyspell loads it adds the following line n top of "ispell-enchant-dictionary-alist" > > ((nil "[[:alpha:]]" "[^[:alpha:]]" "[\n** (process:98935): WARNING **: > 22:05:56.283: Error loading plugin: libvoikko.so.1: cannot open shared > object file: No such file or directory\n\n\n** (process:98935): WARNING > **: 22:05:56.286: Error loading plugin: libhspell.so.0: cannot open > shared object file: No such file or directory\n\n0123456789]" t nil nil > utf-8) These look like local configuration problems on your system, or some bug in Enchant: it tells you that some shared libraries are missing. > I've noticed that enchant-lsmod-2 also produces this error in the > terminal, maybe STDERR should be omitted when generating > ispell-enchant-dictionary-alist or shoud this be reported upstream to > enchant ? The latter, I think. Reuben, can you please comment? From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 30 18:56:47 2020 Received: (at 44318) by debbugs.gnu.org; 30 Oct 2020 22:56:47 +0000 Received: from localhost ([127.0.0.1]:60116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYdKA-0004Fs-Ug for submit@debbugs.gnu.org; Fri, 30 Oct 2020 18:56:47 -0400 Received: from mail-oo1-f44.google.com ([209.85.161.44]:40492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYdK9-0004Fd-59 for 44318@debbugs.gnu.org; Fri, 30 Oct 2020 18:56:45 -0400 Received: by mail-oo1-f44.google.com with SMTP id p73so1967123oop.7 for <44318@debbugs.gnu.org>; Fri, 30 Oct 2020 15:56:45 -0700 (PDT) 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=RacAVqhs4pof8bJh/nroBUOKlWUKycJkooEtMCqfUrk=; b=UKwNe31uGuu+SEKmrZ8X1IeQGQqJrcz0+Sa73rg30G+OG8oOC6iYaEErzQgWOjMWrI U4oVzasIn0Iz25mAgQiKxlRQedREbmM20foai1g8Yc1bt2rCyCCHvznn0EgmMCGli7JL U4oHeGNqo5VQg98sEQJ6MnzHBCl74MzZ+NuvA= 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=RacAVqhs4pof8bJh/nroBUOKlWUKycJkooEtMCqfUrk=; b=calvstu3d58jPt9Q5IbI4NZcCpfZ8Iw2zuBPHbq0NFY6U/WxGSriD3ISX3bKaH8b2k ryPtvBgHXmp8HXpoo86hrn9RsTYyP30HuU7PO+yaNhuD4fn75j6T0BaVttU+9tLYI7PR eV+Db3WeYmyoffm2PFP2Qhuxx4Xzc7cBL40l7xM6lY3EpBXilrMnhMqdp3Q8Ara+xZH2 aEkO5GdeFyenZpqldaPSGBjzr0X9MdB0q6yzvIwMBvBa+Pnnndho19DYDz2G3IGLYKNH ZELzSRcqfiTfnkp0hb+9CrrwkewfLXuxuBTmWZcUJE9C8EBtm2WUHq+quW/jmSI0YR3R zJIA== X-Gm-Message-State: AOAM531JsuOLf0LuEbajOUHUxdcpaTMF3zBAhR04tiif7lbso1xNX1ms ofw1VoM+deKeUhinG6HR5JKT+77TndiXsyLJyxkLlg== X-Google-Smtp-Source: ABdhPJxMNZ3GxRkvN0cl4rZ3t18zhrSkp6SjlBXpGRqKvFsBjEncQEVlWqz7U8KDqpL9G7XQGm0sODw4UDCT/tSa8Vc= X-Received: by 2002:a4a:b503:: with SMTP id r3mr3601747ooo.28.1604098599411; Fri, 30 Oct 2020 15:56:39 -0700 (PDT) MIME-Version: 1.0 References: <83k0v8b1u3.fsf@gnu.org> In-Reply-To: <83k0v8b1u3.fsf@gnu.org> From: Reuben Thomas Date: Fri, 30 Oct 2020 22:56:27 +0000 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000033f7dd05b2eb4fc4" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, dinkonin X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000033f7dd05b2eb4fc4 Content-Type: text/plain; charset="UTF-8" On Fri, 30 Oct 2020 at 07:38, Eli Zaretskii wrote: > > > I've noticed that enchant-lsmod-2 also produces this error in the > > terminal, maybe STDERR should be omitted when generating > > ispell-enchant-dictionary-alist or shoud this be reported upstream to > > enchant ? > > The latter, I think. Reuben, can you please comment? > It looks like Enchant has been built with the voikko (Finnish) provider, but libvoikko is not installed. I don't think it's possible to build Enchant's voikko provider without libvoikko installed, because the provider needs to link against libvoikko. So, this looks like a configuration problem on the user's system. To convince me otherwise would require a recipe to reproduce the problem, I think! If there is a bug, it would definitely be in Enchant, and should be reported to Enchant's bug tracker (details in the package). Thanks! -- https://rrt.sc3d.org --00000000000033f7dd05b2eb4fc4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, 30 Oct 2020 at 07:38, Eli Zaretskii <eliz@gnu.org> wrote:

> I've noticed that enchant-lsmod-2 also produces this error in the<= br> > terminal, maybe STDERR should be omitted when generating
> ispell-enchant-dictionary-alist or shoud this be reported upstream to<= br> > enchant ?

The latter, I think.=C2=A0 Reuben, can you please comment?

It looks like = Enchant has been built with the voikko (Finnish) provider, but libvoikko is= not installed.

I = don't think it's possible to build Enchant's voikko provider wi= thout libvoikko installed, because the provider needs to link against libvo= ikko. So, this looks like a configuration problem on the user's system.= To convince me otherwise would require a recipe to reproduce the problem, = I think!

If there = is a bug, it would definitely be in Enchant, and should be reported to Ench= ant's bug tracker (details in the package). Thanks!

--
--00000000000033f7dd05b2eb4fc4-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 03:29:27 2020 Received: (at 44318-done) by debbugs.gnu.org; 31 Oct 2020 07:29:27 +0000 Received: from localhost ([127.0.0.1]:60450 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYlKJ-0002Bd-CV for submit@debbugs.gnu.org; Sat, 31 Oct 2020 03:29:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55430) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYlKH-0002BS-WC for 44318-done@debbugs.gnu.org; Sat, 31 Oct 2020 03:29:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34885) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYlKC-0001SI-CG; Sat, 31 Oct 2020 03:29:20 -0400 Received: from [176.228.60.248] (port=4126 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kYlKB-0000eN-Fd; Sat, 31 Oct 2020 03:29:20 -0400 Date: Sat, 31 Oct 2020 09:29:03 +0200 Message-Id: <83tuua97ls.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-Reply-To: (message from Reuben Thomas on Fri, 30 Oct 2020 22:56:27 +0000) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend References: <83k0v8b1u3.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318-done Cc: 44318-done@debbugs.gnu.org, dinkonin@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Reuben Thomas > Date: Fri, 30 Oct 2020 22:56:27 +0000 > Cc: dinkonin , 44318@debbugs.gnu.org > > It looks like Enchant has been built with the voikko (Finnish) provider, but libvoikko is not installed. > > I don't think it's possible to build Enchant's voikko provider without libvoikko installed, because the provider > needs to link against libvoikko. So, this looks like a configuration problem on the user's system. To convince > me otherwise would require a recipe to reproduce the problem, I think! > > If there is a bug, it would definitely be in Enchant, and should be reported to Enchant's bug tracker (details in > the package). Thanks! Thanks, I'm therefore closing this bug report. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 03:32:38 2020 Received: (at 44318) by debbugs.gnu.org; 31 Oct 2020 07:32:38 +0000 Received: from localhost ([127.0.0.1]:60459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYlNO-0002Il-4O for submit@debbugs.gnu.org; Sat, 31 Oct 2020 03:32:38 -0400 Received: from mail-ej1-f44.google.com ([209.85.218.44]:39383) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYlNM-0002IU-FE for 44318@debbugs.gnu.org; Sat, 31 Oct 2020 03:32:36 -0400 Received: by mail-ej1-f44.google.com with SMTP id bn26so11675213ejb.6 for <44318@debbugs.gnu.org>; Sat, 31 Oct 2020 00:32:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7gUno/op/0oOWFlqPIQgJYQYgiQZSlM5XExxmIDYUY8=; b=M/B05IsVbXYgoFWpob16SDpuRlHt9DReoB2D3RVbFeX/waNKvANRlbeCDn48fFlZaR +MrZx7fMKf1saLxhVNy3aerzo9QPPQ2ippcWTIKZIzP1o6aGLFNb3sHD5wwcu0It5uNH syxRiwCJlxPmSO/y9Slq0OjDw/hm+jb+1NNzCXfpXvs5ox2K/L05aR4KdwBMHherKv7v vAMvRTZb5/+1aOTvSEFRa0SGjL2O1ZTUKXFeOv0EtbuPcJP6i+SF/zVbEyd5JKbyuaxZ VMl5M8LhXS//mRFTZAcdKatsyANH1y+5ouLHeT5SELbFqZjHLgj0RjsgMeDInY5uP3kD zfQA== 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=7gUno/op/0oOWFlqPIQgJYQYgiQZSlM5XExxmIDYUY8=; b=fB0Q/9fMNQng74O/Qt6dFkkSR1UcX9pEcArp81zq3Ra0l/5+OJwoOrwdTmb1TItPnZ eNtLfTRZ3JSikNmhTaoYhG4rBnD1clQuc/6AQ8ae7yxywg2CLSZCVwUp5xT+BMWebLO4 fMPsWtQcMYevBTuvCyJSd5cWt4/oU/gpYKT16iV+b0hx2uOYdJk3V6mPs848K5MaLu/6 0xS5u8MZWp/49+A8cZtUenb4V0WD95BZZZq2WsEyl6TkL6VXjBfTgSXna14Zde5yloUq dpdcxiu4OZN4ywNhLYhbXznhuWuYVgWSDBvywu+o3r2YHEEuZ2Sji0MckvdBTx9qelTi YJkA== X-Gm-Message-State: AOAM530VACK9YnxCYgK8T2QRQzdV2TsNjP2+hxNnpjwEVBiyHuvJuK3d +hJF/tzAz/EAJ0pSAapJR81GevKuHfSoqVck5Q== X-Google-Smtp-Source: ABdhPJyLUUG/EQpdNZalE1JOh+Eh9pRkyl4LYRS4A+USuw5x0mA2uCjlLyIzvHISJhFS2FIzp09nql0vhUDDKEMHWWU= X-Received: by 2002:a17:906:5052:: with SMTP id e18mr5897309ejk.530.1604129550542; Sat, 31 Oct 2020 00:32:30 -0700 (PDT) MIME-Version: 1.0 References: <83k0v8b1u3.fsf@gnu.org> In-Reply-To: From: dinkonin Date: Sat, 31 Oct 2020 09:32:19 +0200 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Reuben Thomas Content-Type: multipart/alternative; boundary="00000000000008aba505b2f284d2" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: Eli Zaretskii , 44318@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000008aba505b2f284d2 Content-Type: text/plain; charset="UTF-8" Thanks for looking into this , I am able to reproduce it on a new ArchLinux installation with `emacs -Q --eval '(setq ispell-program-name "enchant-2")'` both with Emacs 27 from arch repositories and Emacs 28 built from source. So I think the problem is in the Arch Linux version of the enchant package, It's built with support for all backends but they are not Installed by the package manager because they are marked as optional by the package maintainer. I still think this should not break spell checking in the languages supported by the installed enchant providers. On Sat, Oct 31, 2020 at 12:56 AM Reuben Thomas wrote: > On Fri, 30 Oct 2020 at 07:38, Eli Zaretskii wrote: > >> >> > I've noticed that enchant-lsmod-2 also produces this error in the >> > terminal, maybe STDERR should be omitted when generating >> > ispell-enchant-dictionary-alist or shoud this be reported upstream to >> > enchant ? >> >> The latter, I think. Reuben, can you please comment? >> > > It looks like Enchant has been built with the voikko (Finnish) provider, > but libvoikko is not installed. > > I don't think it's possible to build Enchant's voikko provider without > libvoikko installed, because the provider needs to link against libvoikko. > So, this looks like a configuration problem on the user's system. To > convince me otherwise would require a recipe to reproduce the problem, I > think! > > If there is a bug, it would definitely be in Enchant, and should be > reported to Enchant's bug tracker (details in the package). Thanks! > > -- > https://rrt.sc3d.org > --00000000000008aba505b2f284d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for looking into this ,

I am able to reproduce it on a new ArchLinux installation with `emacs -Q= --eval '(setq ispell-program-name "enchant-2")'` both wi= th Emacs 27 from arch repositories and Emacs 28 built from source.=C2=A0
So I think the problem is in the Arch Linux version of the enchant = package, It's built with support for all backends but they are not Inst= alled by the package manager because they are marked as optional by the pac= kage maintainer.=C2=A0

I still think this shou= ld not break spell checking in the languages supported by the installed enc= hant providers.

On Sat, Oct 31, 2020 at 12:56 AM Reuben Thomas <rrt@sc3d.org> wrote:
<= div class=3D"gmail_quote">
On Fri, 30 = Oct 2020 at 07:38, Eli Zaretskii <eliz@gnu.org> wrote:

> I've noticed that enchant-lsmod-2 also produces this error in the<= br> > terminal, maybe STDERR should be omitted when generating
> ispell-enchant-dictionary-alist or shoud this be reported upstream to<= br> > enchant ?

The latter, I think.=C2=A0 Reuben, can you please comment?

It looks like Enchant has been built w= ith the voikko (Finnish) provider, but libvoikko is not installed.

=
I don't think it's possible to build Enchant's voikko provider= without libvoikko installed, because the provider needs to link against li= bvoikko. So, this looks like a configuration problem on the user's syst= em. To convince me otherwise would require a recipe to reproduce the proble= m, I think!

If there is a bug, it would definitely be in Enchant, = and should be reported to Enchant's bug tracker (details in the package= ). Thanks!

--
--00000000000008aba505b2f284d2-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 03:50:50 2020 Received: (at 44318) by debbugs.gnu.org; 31 Oct 2020 07:50:50 +0000 Received: from localhost ([127.0.0.1]:60471 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYlf0-0002lG-2O for submit@debbugs.gnu.org; Sat, 31 Oct 2020 03:50:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58138) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYlew-0002l1-IR for 44318@debbugs.gnu.org; Sat, 31 Oct 2020 03:50:48 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35022) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYleq-0000Xh-RE; Sat, 31 Oct 2020 03:50:40 -0400 Received: from [176.228.60.248] (port=1459 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kYleq-0000E8-6b; Sat, 31 Oct 2020 03:50:40 -0400 Date: Sat, 31 Oct 2020 09:50:25 +0200 Message-Id: <83o8ki96m6.fsf@gnu.org> From: Eli Zaretskii To: dinkonin In-Reply-To: (message from dinkonin on Sat, 31 Oct 2020 09:32:19 +0200) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend References: <83k0v8b1u3.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, rrt@sc3d.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: dinkonin > Date: Sat, 31 Oct 2020 09:32:19 +0200 > Cc: Eli Zaretskii , 44318@debbugs.gnu.org > > I still think this should not break spell checking in the languages supported by the installed enchant > providers. That might be so, but that's not an Emacs problem, is it? If the speller refuses to run correctly due to misconfigured installation, how can you expect Emacs to fix that problem? Your wish should be directed at the maintainers of the Enchant package on that system. From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 04:38:07 2020 Received: (at 44318) by debbugs.gnu.org; 31 Oct 2020 08:38:07 +0000 Received: from localhost ([127.0.0.1]:60514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYmOl-00040i-7B for submit@debbugs.gnu.org; Sat, 31 Oct 2020 04:38:07 -0400 Received: from mail-ej1-f45.google.com ([209.85.218.45]:45707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYmOk-00040E-5q for 44318@debbugs.gnu.org; Sat, 31 Oct 2020 04:38:06 -0400 Received: by mail-ej1-f45.google.com with SMTP id dk16so11197342ejb.12 for <44318@debbugs.gnu.org>; Sat, 31 Oct 2020 01:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wje4ZdjlDMMmFX2mluAgn0W6D7I4GBkD0MCXIMF8+po=; b=TTawrUoPa0s57wz0SeKfDiiHuGv/1r1YBAF+fq/iwvfeeDUgJvsSf23oaSIkPGXV9I j3dMH12epr+UjWGv0OVbFbsrRNA7ye8WKEQeKPGGw3MAXBoOgZw/FOZ2ax3QWjq8Svuy 10RE7WQlocBCT9Mk4fIANdceZDRjdWKKVxyvXeqYg1Zd2r+Vj7sSTxSE1xUtWmhi1eP1 eKMn1pS5VB2Pmgbwxm/5wYijUxGTQhblfy3331N8ntjY1WfzsKYF4Yt7NoSqNG92EQ6W Jt9hVimIuotC1dF3tSUkil6OA3C3aqX1fcULLE650m3PW2uVbrqE0cxtzRyDfBQzBVxE b6aQ== 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=Wje4ZdjlDMMmFX2mluAgn0W6D7I4GBkD0MCXIMF8+po=; b=KBY3tJKq8FR72542OYxfV0WECAoLs20DdqP/PLCUlS1mnd3ChArPXLB62me35NfTT3 3I7lZtEys4xLO0SXHcOI5ibClSC2Jvonez4HkBWYZnkRbXSyUsNOh1D16KxfgblKuaIU FG0NjhEMObFOLvZpwBnvOzhO+kRRAfGKQSZzYDQNM8B9KZsCYi2Cc/h/fCgBOzZG7RDj bz6Mzkc49MCWJukckdu58yoHBsohaSBYyOCyYdyuNjLsUfLWX7xy5JqWOM3vvNhhc4++ +6YC40hD5ZWlIa28zDIjkHsIZ+1FivJ0XDBwbL457BnNBEXZ0Tqr4JDEKhEAXcfow2zW YzoQ== X-Gm-Message-State: AOAM531RoWmDGn3z1eJRtI6n9PBjjdRtgSSxAZdvUpylxI0yU4fbiwPa QZsXYU/GAfkBJ9jxZ62yw10YJBOroXhVd2DRsw== X-Google-Smtp-Source: ABdhPJzB58HVtFjqqqVIPbhWTRPJB9g8Ov2oczrIcMjycHW6N0e2huWiHjw0IoBNU3yn0WddVcJZ4MnVE++URAoCYTE= X-Received: by 2002:a17:906:5052:: with SMTP id e18mr6038155ejk.530.1604133480297; Sat, 31 Oct 2020 01:38:00 -0700 (PDT) MIME-Version: 1.0 References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> In-Reply-To: <83o8ki96m6.fsf@gnu.org> From: dinkonin Date: Sat, 31 Oct 2020 10:37:49 +0200 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000043fc5705b2f36e55" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, Reuben Thomas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000043fc5705b2f36e55 Content-Type: text/plain; charset="UTF-8" I totally agree with you that this is an upstream problem and I have reported it there. But maybe I have not worded my bug correctly (my English is lacking, sorry). Enchant is working everywhere else on the same system i.e. in AbiWord, Vim, GtkSpell and gedit. It does not work only in Emacs, that's why I reported it here, for the benefit of other Arch users using the package and Emacs. Again I'm sorry for wasting your time. On Sat, Oct 31, 2020 at 9:50 AM Eli Zaretskii wrote: > > From: dinkonin > > Date: Sat, 31 Oct 2020 09:32:19 +0200 > > Cc: Eli Zaretskii , 44318@debbugs.gnu.org > > > > I still think this should not break spell checking in the languages > supported by the installed enchant > > providers. > > That might be so, but that's not an Emacs problem, is it? If the > speller refuses to run correctly due to misconfigured installation, > how can you expect Emacs to fix that problem? Your wish should be > directed at the maintainers of the Enchant package on that system. > --00000000000043fc5705b2f36e55 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I totally=C2=A0agree with you that this is an upstream pro= blem and I have reported it there. But maybe I have not worded my bug corre= ctly (my English is lacking, sorry). Enchant is working everywhere else on = the same system i.e. in AbiWord, Vim, GtkSpell and gedit. It does not work = only in Emacs, that's why I reported it here,=C2=A0for the benefit of o= ther Arch users using=C2=A0the package and Emacs.

Again I'= m sorry for wasting your time.

On Sat, Oct 31, 2020 at 9:50 AM E= li Zaretskii <eliz@gnu.org> wrote= :
> From: din= konin <dinkonin@= gmail.com>
> Date: Sat, 31 Oct 2020 09:32:19 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 44318@debbugs.gnu.org
>
> I still think this should not break spell checking in the languages su= pported by the installed enchant
> providers.

That might be so, but that's not an Emacs problem, is it?=C2=A0 If the<= br> speller refuses to run correctly due to misconfigured installation,
how can you expect Emacs to fix that problem?=C2=A0 Your wish should be
directed at the maintainers of the Enchant package on that system.
--00000000000043fc5705b2f36e55-- From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 31 05:18:01 2020 Received: (at 44318) by debbugs.gnu.org; 31 Oct 2020 09:18:02 +0000 Received: from localhost ([127.0.0.1]:60546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYn1N-00051b-Jz for submit@debbugs.gnu.org; Sat, 31 Oct 2020 05:18:01 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYn1M-00051I-F1 for 44318@debbugs.gnu.org; Sat, 31 Oct 2020 05:18:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35853) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYn1G-0005wu-UN; Sat, 31 Oct 2020 05:17:55 -0400 Received: from [176.228.60.248] (port=1093 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kYn1G-0008NL-A1; Sat, 31 Oct 2020 05:17:54 -0400 Date: Sat, 31 Oct 2020 11:17:39 +0200 Message-Id: <83k0v6hhzg.fsf@gnu.org> From: Eli Zaretskii To: dinkonin In-Reply-To: (message from dinkonin on Sat, 31 Oct 2020 10:37:49 +0200) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, rrt@sc3d.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: dinkonin > Date: Sat, 31 Oct 2020 10:37:49 +0200 > Cc: Reuben Thomas , 44318@debbugs.gnu.org > > I totally agree with you that this is an upstream problem and I have reported it there. But maybe I have not > worded my bug correctly (my English is lacking, sorry). Enchant is working everywhere else on the same > system i.e. in AbiWord, Vim, GtkSpell and gedit. It does not work only in Emacs, that's why I reported it here, > for the benefit of other Arch users using the package and Emacs. I don't know how it succeeds working in those other environments, but I don't think Emacs should work around clear problems in installing the spell-checker. From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 01 17:24:05 2020 Received: (at 44318) by debbugs.gnu.org; 1 Nov 2020 22:24:05 +0000 Received: from localhost ([127.0.0.1]:38880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZLld-0008AO-4a for submit@debbugs.gnu.org; Sun, 01 Nov 2020 17:24:05 -0500 Received: from mail-oi1-f171.google.com ([209.85.167.171]:46487) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZLla-00089t-HT for 44318@debbugs.gnu.org; Sun, 01 Nov 2020 17:24:03 -0500 Received: by mail-oi1-f171.google.com with SMTP id x1so12787019oic.13 for <44318@debbugs.gnu.org>; Sun, 01 Nov 2020 14:24:02 -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=mbO82nADLXWtxeC47FJLIOA7skZb9pTFQD3E5fS8w1w=; b=MMbLcJyJWBNVGSSahO3NH7oQVzCtEEfqicn6pzHJHAf40ST7Vo8JdFfpkwYJFtygoL MoiJn1J0WctFzsEZe39W99nM3EplcJXxe3rFjLaX+zBy9IUIJC7+/OmzUc84OEJOJb8l i0od38/eSN2+OIJo+xYMI9+rjWHt46AGnyNTA= 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=mbO82nADLXWtxeC47FJLIOA7skZb9pTFQD3E5fS8w1w=; b=t2YBmjpGj/SwOTPKnH3QJ7wsLzRRcWG/UwPx3lhVFsYG9eNxozpSmT02ZT09eQobUb 32psIRaP+5mb1JV+ehUxq3+YzaL6qdT/eDCTgRdbSkPcGNO7byIJzqQUg+vyOqb5d3l8 oC7AnmLJop35O6RUtS2ote6yKTML7+I64JTkh6gW0P7o/ii6rbiZIvSZMJR/vUNDYK3J znbAk4kuldu4wJ+Mzgr3GUUZnvFNoxjmstbusAlSvIKQvuC4CY18zDiLfXu5t2Yb5Dn1 5T1neuUnFzYx4F+ApEP47Ajsm903kSDL/lKZolj8KapCdC8cIBufLcabZC6wgEpl87yM zkaQ== X-Gm-Message-State: AOAM533zsbaXsxhz34xSHZsvN7JEYQFbX0m73qpjAKDqwwdtF84JM6R7 thIMrSVtyAxo7BoA8RoPG8xut3P2+i7D8PB4mzRw0Q== X-Google-Smtp-Source: ABdhPJwqgJ+Ml6h/lYZoEl5PqqjnIzaO1UDZoZA2OfJbwKFEnqmNsnetlLakZkJeRY6ujErk7ysNWBdlfe/JWL6vVJA= X-Received: by 2002:a05:6808:8ea:: with SMTP id d10mr8462937oic.62.1604269436713; Sun, 01 Nov 2020 14:23:56 -0800 (PST) MIME-Version: 1.0 References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> In-Reply-To: <83k0v6hhzg.fsf@gnu.org> From: Reuben Thomas Date: Sun, 1 Nov 2020 22:23:44 +0000 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000e6530705b31315b8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, dinkonin X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000e6530705b31315b8 Content-Type: text/plain; charset="UTF-8" On Sat, 31 Oct 2020 at 09:17, Eli Zaretskii wrote: > > From: dinkonin > > Date: Sat, 31 Oct 2020 10:37:49 +0200 > > Cc: Reuben Thomas , 44318@debbugs.gnu.org > > > > I totally agree with you that this is an upstream problem and I have > reported it there. But maybe I have not > > worded my bug correctly (my English is lacking, sorry). Enchant is > working everywhere else on the same > > system i.e. in AbiWord, Vim, GtkSpell and gedit. It does not work only > in Emacs, that's why I reported it here, > > for the benefit of other Arch users using the package and Emacs. > > I don't know how it succeeds working in those other environments, but > I don't think Emacs should work around clear problems in installing > the spell-checker. > I've had a bit more time to think about this now, and I think I understand better what is going on. First, it's pretty obvious why this isn't a problem for programs other than Emacs: they ignore the error messages. I think Enchant is correct to generate the errors, as it shows that it has been mis-installed. I looked at the Arch package, and it depends on libvoikko, so I'm surprised you're getting these errors in the first place. However, I think Emacs should be able (like other Enchant-using programs) to cope with this problem, particularly as all it should have to do is ignore stderr. I think this can be achieved by changing the definition of ispell--call-enchant-lsmod to: (defun ispell--call-enchant-lsmod (&rest args) "Call enchant-lsmod with ARGS and return the output as string." (with-output-to-string (apply #'ispell-call-process (replace-regexp-in-string "enchant\\(-[0-9]\\)?\\'" "enchant-lsmod\\1" ispell-program-name) nil '(t nil) nil args))) (I can't see any reason to use `with-current-buffer` either; am I missing something?) -- https://rrt.sc3d.org --000000000000e6530705b31315b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, 31 Oct 2020 at= 09:17, Eli Zaretskii <eliz@gnu.org&= gt; wrote:
> From: dinkonin <dinkonin@gmail.com>
> Date: Sat, 31 Oct 2020 10:37:49 +0200
> Cc: Reuben Thomas <rrt@sc3d.org>, 44318@debbugs.gnu.org
>
> I totally agree with you that this is an upstream problem and I have r= eported it there. But maybe I have not
> worded my bug correctly (my English is lacking, sorry). Enchant is wor= king everywhere else on the same
> system i.e. in AbiWord, Vim, GtkSpell and gedit. It does not work only= in Emacs, that's why I reported it here,
> for the benefit of other Arch users using the package and Emacs.

I don't know how it succeeds working in those other environments, but I don't think Emacs should work around clear problems in installing
the spell-checker.

I've had a= bit more time to think about this now, and I think I understand better wha= t is going on.

First, = it's pretty obvious why this isn't a problem for programs other tha= n Emacs: they ignore the error messages.

=
I think Enchant is correct to generate the errors, as it= shows that it has been mis-installed. I looked at the Arch package, and it= depends on libvoikko, so I'm surprised you're getting these errors= in the first place.

H= owever, I think Emacs should be able (like other Enchant-using programs) to= cope with this problem, particularly as all it should have to do is ignore= stderr.

I think this = can be achieved by changing the definition of ispell--call-enchant-lsmod to= :

(defun ispell--call-= enchant-lsmod (&rest args)
=C2=A0 "Call enchant-lsmod with ARGS= and return the output as string."
=C2=A0 (with-output-to-string=C2=A0 =C2=A0 (apply #'ispell-call-process
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0(replace-regexp-in-string "enchant\\(-[0-9]\\)?\\'= ;"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"= enchant-lsmod\\1"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0ispell-program-name)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= nil '(t nil) nil args)))

(I can't see any reason to use `with-current-buffer` either; a= m I missing something?)

--
--000000000000e6530705b31315b8-- From debbugs-submit-bounces@debbugs.gnu.org Sun Nov 01 22:34:52 2020 Received: (at 44318) by debbugs.gnu.org; 2 Nov 2020 03:34:52 +0000 Received: from localhost ([127.0.0.1]:39147 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZQcO-00015P-0U for submit@debbugs.gnu.org; Sun, 01 Nov 2020 22:34:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZQcN-00015D-2r for 44318@debbugs.gnu.org; Sun, 01 Nov 2020 22:34:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37832) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZQcH-0007Im-I3; Sun, 01 Nov 2020 22:34:45 -0500 Received: from [176.228.60.248] (port=4645 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kZQcG-0003mR-WD; Sun, 01 Nov 2020 22:34:45 -0500 Date: Mon, 02 Nov 2020 05:34:33 +0200 Message-Id: <83h7q8e8ja.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-Reply-To: (message from Reuben Thomas on Sun, 1 Nov 2020 22:23:44 +0000) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, dinkonin@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Reuben Thomas > Date: Sun, 1 Nov 2020 22:23:44 +0000 > Cc: dinkonin , 44318@debbugs.gnu.org > > I think Enchant is correct to generate the errors, as it shows that it has been mis-installed. I looked at the > Arch package, and it depends on libvoikko, so I'm surprised you're getting these errors in the first place. > > However, I think Emacs should be able (like other Enchant-using programs) to cope with this problem, > particularly as all it should have to do is ignore stderr. > > I think this can be achieved by changing the definition of ispell--call-enchant-lsmod to: Thanks, but I'm not interested in working around installation problems of programs we invoke. It's a slippery slope, with never-ending additional requests we will have to honor. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 03:15:00 2020 Received: (at 44318) by debbugs.gnu.org; 2 Nov 2020 08:15:00 +0000 Received: from localhost ([127.0.0.1]:39623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZUzU-0008En-Be for submit@debbugs.gnu.org; Mon, 02 Nov 2020 03:15:00 -0500 Received: from mail-ej1-f54.google.com ([209.85.218.54]:45761) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZUzS-0008Eb-DN for 44318@debbugs.gnu.org; Mon, 02 Nov 2020 03:14:59 -0500 Received: by mail-ej1-f54.google.com with SMTP id dk16so17066774ejb.12 for <44318@debbugs.gnu.org>; Mon, 02 Nov 2020 00:14:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=k/HnqN4mh5vybgdUx7zg3Vl1Y6YlkajtCVfWh+FP1Ow=; b=nHikwMKM6kTnKWdm4VjRitOO1nT/zDKpFsvO3S7bktgv7rXzv1hu4FtC5+VWgus1KX r475a939ioZF7ZtOlAX8RoPMQNZPtkdRAkLqO1cpuoAPQbedNd6SoOxTRSRYvNWGaYlL F9Zq7ixiRLnIRthKj+PbByO6juldTKWHwyWyhTFdB7SPfxhD8S+FQgn+hCq2Yw2X7WAY YTaDjRrlnsS0nAykwyqby0oZOBsKFV9yUQ6Phg63r8D0Df/+Ea6jdyvVfVAmfs2Shrky 6j8vQZAnNNyxpI5aTtltreAGxsUP/jeYVcavlKLLIskV3I0DsLtR4fyfTZQ5vKwt9fFf 009g== 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=k/HnqN4mh5vybgdUx7zg3Vl1Y6YlkajtCVfWh+FP1Ow=; b=Ptz/38nTBd1DBb4QYVN8vqDtjDC4GjIEo76OR8bCOYcUdS4p4FVkQyoPDCGw52jWTP hk+tdavFt97EQrtLqldsa1L38nZb168f4WeHjOKCoQrm0UgIMkelxw9DVati5PUE/sPV Jzee1k9QgmOvM08uvFoRyb/oRDi0fOxlI6AVKG7Ar87r6oErM9IRalyPy17qEcfOaFzs nIToqtVk8lTVCPC9wSj7O/9SCkl6axIreA7u7jMfWecNa+f4oKjTfeZJGuSkGcaKn9Te cPHMiD+OIKadr7X95Zv20/kYEO/n8p/vtOE3THLsJ0dI6jq2XywEBfbkIQc7zno20IvS PWDw== X-Gm-Message-State: AOAM532oNKfBFkaa+jaQUUuXwqLBZfQH3MHf1dde2rKfxTWua1ETNoeg XVpernbf84K4IJpe7clx1U/wV84x8kiV+9YfKQ== X-Google-Smtp-Source: ABdhPJxA6BZEzqjZepx2y6DbzFR6YsU1zvFrW/c/KuQlpkhpbTyZrZ0BonOq69ku9NYViDN+9rjgCi8EdXyx1L1OFaI= X-Received: by 2002:a17:906:c1ce:: with SMTP id bw14mr14145369ejb.302.1604304892559; Mon, 02 Nov 2020 00:14:52 -0800 (PST) MIME-Version: 1.0 References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> <83h7q8e8ja.fsf@gnu.org> In-Reply-To: <83h7q8e8ja.fsf@gnu.org> From: dinkonin Date: Mon, 2 Nov 2020 10:14:41 +0200 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000003b86cb05b31b57fd" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, Reuben Thomas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000003b86cb05b31b57fd Content-Type: text/plain; charset="UTF-8" I agree with Eli Zaretskii, after some further investigation I've narrowed it down to an issue with the arch packaging that does not exist in other non arch-based distributions. I reported the issue in https://bugs.archlinux.org/task/68499, and I hope this will be resolved by the package maintainer. Again sorry for wasting your time and thank you both for the swift responses. On Mon, Nov 2, 2020 at 5:34 AM Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Sun, 1 Nov 2020 22:23:44 +0000 > > Cc: dinkonin , 44318@debbugs.gnu.org > > > > I think Enchant is correct to generate the errors, as it shows that it > has been mis-installed. I looked at the > > Arch package, and it depends on libvoikko, so I'm surprised you're > getting these errors in the first place. > > > > However, I think Emacs should be able (like other Enchant-using > programs) to cope with this problem, > > particularly as all it should have to do is ignore stderr. > > > > I think this can be achieved by changing the definition of > ispell--call-enchant-lsmod to: > > Thanks, but I'm not interested in working around installation problems > of programs we invoke. It's a slippery slope, with never-ending > additional requests we will have to honor. > --0000000000003b86cb05b31b57fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Eli Zaretskii,
=C2=A0after some further i= nvestigation I've narrowed it down to an issue with the arch packaging= =C2=A0that does not exist in other non arch-based distributions. I reported= the issue in=C2=A0https:= //bugs.archlinux.org/task/68499, and I hope this will be resolved=C2=A0= by the package maintainer.
Again sorry for wasting your time and thank = you both for the swift responses.

On Mon, Nov 2, 2020 at 5:34 AM= Eli Zaretskii <eliz@gnu.org> wro= te:
> From: R= euben Thomas <rrt@sc3d= .org>
> Date: Sun, 1 Nov 2020 22:23:44 +0000
> Cc: dinkonin <dinkonin@gmail.com>, 44318@debbugs.gnu.org
>
> I think Enchant is correct to generate the errors, as it shows that it= has been mis-installed. I looked at the
> Arch package, and it depends on libvoikko, so I'm surprised you= 9;re getting these errors in the first place.
>
> However, I think Emacs should be able (like other Enchant-using progra= ms) to cope with this problem,
> particularly as all it should have to do is ignore stderr.
>
> I think this can be achieved by changing the definition of ispell--cal= l-enchant-lsmod to:

Thanks, but I'm not interested in working around installation problems<= br> of programs we invoke.=C2=A0 It's a slippery slope, with never-ending additional requests we will have to honor.
--0000000000003b86cb05b31b57fd-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 03:35:33 2020 Received: (at 44318) by debbugs.gnu.org; 2 Nov 2020 08:35:33 +0000 Received: from localhost ([127.0.0.1]:39664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZVJN-0000LT-1v for submit@debbugs.gnu.org; Mon, 02 Nov 2020 03:35:33 -0500 Received: from mail-oi1-f182.google.com ([209.85.167.182]:44506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZVJL-0000LA-4l for 44318@debbugs.gnu.org; Mon, 02 Nov 2020 03:35:31 -0500 Received: by mail-oi1-f182.google.com with SMTP id k27so13875732oij.11 for <44318@debbugs.gnu.org>; Mon, 02 Nov 2020 00:35:31 -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=Ngb1aAMKnhcXBX2MKblR+7zlSBv9X0o3H4/IjmD4B8M=; b=B/PKAY3PxkjBymANIjqEW6TahFvBG+iqZRdp9p2+/GmAN5Rp3auCs1bhVEP+RVU7BM x+09MlvEz9TbLI0PuiZBuxWXaw8juRuELGoExRjzBS0JY5pYGMEyEuIgctqIWJSrcC1P lpD1Ni2LizsFiEt5CkFvnfiKkiKXppVuhRGs4= 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=Ngb1aAMKnhcXBX2MKblR+7zlSBv9X0o3H4/IjmD4B8M=; b=jLfoNsLit1gEVCdFG4dV3rDWv0tYyplivgjWkcCeQLwPKWt5kVMn38nYLsHSbuHP/P 8Rvm4HEvhT/G3s2AXJcE4hm0DJzw2t3OP9HclW58kt3LqNIt++ZCRY7K1aD49zTETwUt IV6riIagvrRSdoOAwHS13+rAl19fDF9hLmQqa3p8dfCz1Ujv7Q1+hm/bWhhQxLRcXHqX 4F97ev28wVBB3UiSl8A/lCWZHeX/Q4sfcOtyW4IoZrzE3bW6/9JNwEHcTYjL9K+9IZmc 8AeTd2CFvI4f1Q/cQaVaY8PS4po7E27BbqHZaj2Vb6BMZws4qWc2BC94qhNvqPew0s9V oJRA== X-Gm-Message-State: AOAM532JGsGL5PKlKmNTlDNWXHNkJBkpvejP1Jcg/On9wkMVskpUwzN3 n0T0loICCb4ONgZe5OHNalpe1mj4tJyltLexETb7xA== X-Google-Smtp-Source: ABdhPJzu4XiPybhNE69tLUkCCoOYq2LZkEwwLXBMBgM6qqls5+EpkCukG6Gx2UIEcCH5BD+LUCQBqAKJ1qnyfanUXoY= X-Received: by 2002:a05:6808:8ea:: with SMTP id d10mr9519955oic.62.1604306125306; Mon, 02 Nov 2020 00:35:25 -0800 (PST) MIME-Version: 1.0 References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> <83h7q8e8ja.fsf@gnu.org> In-Reply-To: <83h7q8e8ja.fsf@gnu.org> From: Reuben Thomas Date: Mon, 2 Nov 2020 08:35:13 +0000 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000b5d69905b31ba007" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, dinkonin X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000b5d69905b31ba007 Content-Type: text/plain; charset="UTF-8" On Mon, 2 Nov 2020 at 03:34, Eli Zaretskii wrote: > > Thanks, but I'm not interested in working around installation problems > of programs we invoke. It's a slippery slope, with never-ending > additional requests we will have to honor. > The reporter and I seem to have swapped positions on this! 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. -- https://rrt.sc3d.org --000000000000b5d69905b31ba007 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 2 Nov 2020 at 03:34, Eli Zaretskii <eliz@gnu.org> wrote:

Thanks, but I'm not interested in working around installation problems<= br> of programs we invoke.=C2=A0 It's a slippery slope, with never-ending additional requests we will have to honor.

The reporter a= nd I seem to have swapped positions on this!

I believe that the ispell.el code (which I wrote) is bu= ggy: it should not be incorporating warnings into its output.

Also, the patch I offered is a simp= lification of the original code. So, I don't think we are losing here.<= /div>

Eli, I quite agree wit= h your sentiment, and I would certainly not advocate installing a workaroun= d 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 pro= blem.

--
<= /div> --000000000000b5d69905b31ba007-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 10:41:30 2020 Received: (at 44318) by debbugs.gnu.org; 2 Nov 2020 15:41:30 +0000 Received: from localhost ([127.0.0.1]:42202 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZbxa-0003Hv-CC for submit@debbugs.gnu.org; Mon, 02 Nov 2020 10:41:30 -0500 Received: from mail-ed1-f53.google.com ([209.85.208.53]:42003) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZbxY-0003Hf-NI for 44318@debbugs.gnu.org; Mon, 02 Nov 2020 10:41:29 -0500 Received: by mail-ed1-f53.google.com with SMTP id a71so9425459edf.9 for <44318@debbugs.gnu.org>; Mon, 02 Nov 2020 07:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EVllGUzTU2yVvgfWeXJPRr2EPNWbWAMg3QPhmhbHZYE=; b=ueckCBrdq1iWePy+pGl4hy+NRJfpsp+3xutsBAoL+jlAITn9p/mgMEmBSkauNtgmLs ZgMhtAaMqkkIctAWtacTA/fTpF6tAScp0rmPepnO5JIxS43WTE0zFD72/gCGVNJollpY DciX7adFOhKi5qZFIjvbaEZ47dIF2Kx8tsq4xsRzdgPlp/Z0h/sAzSXDj3ncWTYtFHUf 4hQY14P5qEb/T8LrJcS+4BwGk53YetnwxuXNpRFfiOPV75dhEDb4Ik+7/X/f5/kEQUgB K1UJKHJrvL7hcmVn5iX67KdGP92wycnSAqWCX7M7O89hP2G18PMahB06kcYIlpODspvN SLHw== 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=EVllGUzTU2yVvgfWeXJPRr2EPNWbWAMg3QPhmhbHZYE=; b=gWCOUwX0m2mIH2qpyPVovj/zH2XWkxwgVBlTF/zH+xkqFiJcrccGqVlVFRfHxfvATt tuP71FD5O6hfaJDoSFOaGDiVLTCJ6jy/Axkj387HQWmnByyQ6aFMiFLQIkibChJokCEe b9bRwB61RTUPonD1/7BkcEtgyyT/GDniGI8A0fqHgUc2FGyCdK5XWk5xN1mfsIWj397B T8i0mpUkeXTkn4Pbp2SvK+UlvGdl96GQNEKEk3/Afd8oD+GjPHk1d4TUDzEm+g4t/rAX RXByNzKDLCVatnXUZtsReOLZwFOHyqqZdF5ayzWGldhv3On2JXrPwAD+6xz48mDWtdbP aNLA== X-Gm-Message-State: AOAM533krQioJdIWy5xZ+99FRMw9EdSseqV6i0/hraHDpPBQofhUEc2x lGEweJ/S8pe/T0xQBuDUDMRkL08qxRW+b0HXsw== X-Google-Smtp-Source: ABdhPJzcR8d1fou51rvSD0HOp/WPQ3ygdiEpETtDaj8TjetejxeARDslyXpvW+P/uxRpm9XkuZuW/JEcHVc/n1Ju/8Q= X-Received: by 2002:a05:6402:1d3b:: with SMTP id dh27mr10116416edb.183.1604331682802; Mon, 02 Nov 2020 07:41:22 -0800 (PST) MIME-Version: 1.0 References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> <83h7q8e8ja.fsf@gnu.org> In-Reply-To: From: dinkonin Date: Mon, 2 Nov 2020 17:41:11 +0200 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Reuben Thomas Content-Type: multipart/alternative; boundary="0000000000000e2ef905b3219419" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: Eli Zaretskii , 44318@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000000e2ef905b3219419 Content-Type: text/plain; charset="UTF-8" Thanks you Reuben Thomas, I hope this gets resolved in the best way possible, Unfortunately Arch maintainers have declined looking at this with the following Catch 22 comment: >> FS#68499 - [enchant] Warnings about optional dependencies.>> Reason for closing: Not a bug >> Additional comments about closing: Warnings are not errors. If emacs Flyspell doesn't work upon seeing enchant *warnings*, Flyspell should be fixed As for me, I think I will refrain from reporting more bugs for now. Be safe. On Mon, Nov 2, 2020 at 10:35 AM Reuben Thomas wrote: > On Mon, 2 Nov 2020 at 03:34, Eli Zaretskii wrote: > >> >> Thanks, but I'm not interested in working around installation problems >> of programs we invoke. It's a slippery slope, with never-ending >> additional requests we will have to honor. >> > > The reporter and I seem to have swapped positions on this! > > 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. > > -- > https://rrt.sc3d.org > --0000000000000e2ef905b3219419 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks you Reuben Thomas, I hope this gets resolved i= n the best way possible,=C2=A0

Unfortunately Arch = maintainers have declined looking at this with the following Catch 22 comme= nt:

>> FS#68499 - [enchant] Warnings about option= al dependencies.>> Reason for closing: Not a bug
>> Addition= al comments about closing: Warnings are not errors. If emacs Flyspell doesn= 't work upon seeing enchant *warnings*, Flyspell should be fixed
As for me, I think I will refrain from reporting more bug= s for now.
Be safe.

On Mon, Nov = 2, 2020 at 10:35 AM Reuben Thomas <rrt@s= c3d.org> wrote:
On Mon, 2 Nov 2020 at 03:34, Eli Zaretskii <eliz@gnu.org> wrote:
=

Thanks, but I'm not interested in working around installation problems<= br> of programs we invoke.=C2=A0 It's a slippery slope, with never-ending additional requests we will have to honor.

The reporter a= nd I seem to have swapped positions on this!

I believe that the ispell.el code (which I wrote) is bu= ggy: it should not be incorporating warnings into its output.

Also, the patch I offered is a simp= lification of the original code. So, I don't think we are losing here.<= /div>

Eli, I quite agree wit= h your sentiment, and I would certainly not advocate installing a workaroun= d 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 pro= blem.

--
--0000000000000e2ef905b3219419-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 10:41:58 2020 Received: (at 44318) by debbugs.gnu.org; 2 Nov 2020 15:41:58 +0000 Received: from localhost ([127.0.0.1]:42205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZby1-0003Id-Pv for submit@debbugs.gnu.org; Mon, 02 Nov 2020 10:41:57 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57860) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZby0-0003IR-Qp for 44318@debbugs.gnu.org; Mon, 02 Nov 2020 10:41:57 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48464) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZbxv-0002H3-Ai; Mon, 02 Nov 2020 10:41:51 -0500 Received: from [176.228.60.248] (port=1504 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kZbxu-0001h0-Ow; Mon, 02 Nov 2020 10:41:51 -0500 Date: Mon, 02 Nov 2020 17:41:41 +0200 Message-Id: <83a6vzepfu.fsf@gnu.org> From: Eli Zaretskii To: dinkonin In-Reply-To: (message from dinkonin on Mon, 2 Nov 2020 10:14:41 +0200) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> <83h7q8e8ja.fsf@gnu.org> X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, rrt@sc3d.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) > From: dinkonin > Date: Mon, 2 Nov 2020 10:14:41 +0200 > Cc: Reuben Thomas , 44318@debbugs.gnu.org > > Again sorry for wasting your time and thank you both for the swift responses. No need to apologize. Thank you for your interest in Emacs. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 10:43:45 2020 Received: (at 44318) by debbugs.gnu.org; 2 Nov 2020 15:43:45 +0000 Received: from localhost ([127.0.0.1]:42214 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZbzl-0003Lk-D4 for submit@debbugs.gnu.org; Mon, 02 Nov 2020 10:43:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58428) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZbzj-0003LX-OR for 44318@debbugs.gnu.org; Mon, 02 Nov 2020 10:43:44 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48500) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZbze-0002UR-FJ; Mon, 02 Nov 2020 10:43:38 -0500 Received: from [176.228.60.248] (port=1611 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kZbzd-0001pD-9Q; Mon, 02 Nov 2020 10:43:38 -0500 Date: Mon, 02 Nov 2020 17:43:27 +0200 Message-Id: <838sbjepcw.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-Reply-To: (message from Reuben Thomas on Mon, 2 Nov 2020 08:35:13 +0000) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> <83h7q8e8ja.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, dinkonin@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. Moreover, no one said that some client of Enchant, current or future, won't decide to produce non-error output on stderr. Sorry. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 10:49:40 2020 Received: (at 44318) by debbugs.gnu.org; 2 Nov 2020 15:49:40 +0000 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 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 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) MIME-Version: 1.0 References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> <83h7q8e8ja.fsf@gnu.org> <838sbjepcw.fsf@gnu.org> In-Reply-To: <838sbjepcw.fsf@gnu.org> From: Reuben Thomas Date: Mon, 2 Nov 2020 15:49:19 +0000 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000001e53b605b321b1e0" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, dinkonin X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --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-- From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 11:11:03 2020 Received: (at 44318) by debbugs.gnu.org; 2 Nov 2020 16:11:03 +0000 Received: from localhost ([127.0.0.1]:42322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZcQA-0008O2-Pe for submit@debbugs.gnu.org; Mon, 02 Nov 2020 11:11:03 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZcQ9-0008NS-IS for 44318@debbugs.gnu.org; Mon, 02 Nov 2020 11:11:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49238) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZcQ4-0006YV-79; Mon, 02 Nov 2020 11:10:56 -0500 Received: from [176.228.60.248] (port=3300 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kZcQ3-0000pK-MP; Mon, 02 Nov 2020 11:10:56 -0500 Date: Mon, 02 Nov 2020 18:10:46 +0200 Message-Id: <83y2jjd9ix.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-Reply-To: (message from Reuben Thomas on Mon, 2 Nov 2020 15:49:19 +0000) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend References: <83k0v8b1u3.fsf@gnu.org> <83o8ki96m6.fsf@gnu.org> <83k0v6hhzg.fsf@gnu.org> <83h7q8e8ja.fsf@gnu.org> <838sbjepcw.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, dinkonin@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Reuben Thomas > Date: Mon, 2 Nov 2020 15:49:19 +0000 > Cc: dinkonin , 44318@debbugs.gnu.org > > 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.) OK, I agree to this change, under protest. From debbugs-submit-bounces@debbugs.gnu.org Mon Nov 02 16:49:53 2020 Received: (at 44318) by debbugs.gnu.org; 2 Nov 2020 21:49:53 +0000 Received: from localhost ([127.0.0.1]:42794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZhi4-0004BQ-JR for submit@debbugs.gnu.org; Mon, 02 Nov 2020 16:49:53 -0500 Received: from mail-ot1-f42.google.com ([209.85.210.42]:39897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZhi2-0004BC-Mr for 44318@debbugs.gnu.org; Mon, 02 Nov 2020 16:49:51 -0500 Received: by mail-ot1-f42.google.com with SMTP id z16so8906035otq.6 for <44318@debbugs.gnu.org>; Mon, 02 Nov 2020 13:49:50 -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=uAxy/cOPu41/Gh/C+FZpvEafymkl2myN0XqfUoLMRm8=; b=LCxjGdGi3YWpOhcuD+CSGMXFYJOxcJ+0Bh59LPj86IJuhyHeXtzof26PxncIu1xHLE WNbvlnEPKg9JUYjXJr6rse84ipVvVeL/oPbAqMOfTSDw0TUdCMjeWc1O72+CWScAwAOX nnqeWOL82Yh3ZRmHwdBan6jKG51iwSu4hPc7I= 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=uAxy/cOPu41/Gh/C+FZpvEafymkl2myN0XqfUoLMRm8=; b=TtQnpHcwjg+uk74IiwTRyg8mwivkZrUGWQuuNyUwdgq2jd7EuPSyXpJMETghcModog NoS1KvKqM09tkhwxFZMjX5TJaVud83RPMDWuDkMXI96mxYiFtfLUxfzwpQfuQv8njXeL rs0MugObr8oME0m8P62a90edJcv8W0KThTEl9e7mc4GSLkWJhGPt8j6xocVul/42IWc3 gztDsHjban+QrgtaJ4BQ0DyASgBtfIKxSCJCXD2DVZPKGKhhv+L9qBit4gHKIY0SNbfl jieiVNgufdoDSiIrLUJ1nulheOnINMzpcioMj39lj9AeGE9XVNqy82WwF6QPIC5tQrwg Q1pg== X-Gm-Message-State: AOAM5339UJgUaXv+AxM2RvWIhnTYQpZFXPB+nXNJLJ6p3brsPEYpY1LO 1mJxCQulPGyeiQEYOGOhXkJr8vdANrnB7ad1SylPng== X-Google-Smtp-Source: ABdhPJwiTEvbtmI1vUs6VJ3cF6ZhwbOeIW09w6o8J3q0HpLWppEfCDsUWfwOP43Hmq5JeeHwB+PsfmBpZ0LtdpQEx+A= X-Received: by 2002:a9d:7848:: with SMTP id c8mr13706222otm.120.1604353784771; Mon, 02 Nov 2020 13:49:44 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <83y2jjd9ix.fsf@gnu.org> From: Reuben Thomas Date: Mon, 2 Nov 2020 21:49:33 +0000 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/mixed; boundary="000000000000700a9405b326b966" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, dinkonin X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000700a9405b326b966 Content-Type: multipart/alternative; boundary="000000000000700a9205b326b964" --000000000000700a9205b326b964 Content-Type: text/plain; charset="UTF-8" On Mon, 2 Nov 2020 at 16:10, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Mon, 2 Nov 2020 15:49:19 +0000 > > Cc: dinkonin , 44318@debbugs.gnu.org > > > > 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.) > > OK, I agree to this change, under protest. > Thanks Eli, I have installed it; of course, contact me if it causes any problems. After installing that patch, I discovered that in ispell--call-enchant-lsmod, it did need to use with-current-buffer, so I have installed a patch that restores the use of with-current-buffer; apologies for getting that wrong first time. In fact, this change is not sufficient to fix the original problem, because the enchant program outputs the same warning when a provider module cannot be loaded. In this case, stderr is added to the list of suggested words. Again, I believe Enchant is correct to output a warning, and again, I believe Emacs is wrong to amalgamate stderr and stdout. I attach three patches that do the following: 1. Simplify ispell-call-process{,-region} by factoring out the macro ispell-with-safe-default-directory. 2. I also found that ispell-check-version can be simplified slightly: aspell has accepted -vv since 2004, so use it always. 3. When spell-checking, collect only standard output. This leaves some spell-checker-specific calls to ispell-call-process to collect stderr as well, which as far as I can tell is needed in only one case, ispell-find-hunspell-dictionaries; but it doesn't hurt to leave the rest unchanged. I have tested this patch with all supported spellcheckers (ispell, aspell, hunspell, enchant). --000000000000700a9205b326b964 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, 2 Nov 20= 20 at 16:10, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Mon, 2 Nov 2020 15:49:19 +0000
> Cc: dinkonin <dinkonin@gmail.com>, 44318@debbugs.gnu.org
>
> So I, as upstream maintainer, am telling you that indeed, it is not co= rrect 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 th= at currently, because the warnings are not
> written for users. Other programs that use Enchant do not show these w= arnings, they simply omit providers
> that do not load from the list of languages/spelling checkers that are= available.)

OK, I agree to this change, under protest.

Thanks Eli, I hav= e installed it; of course, contact me if it causes any problems. After inst= alling that patch, I discovered that in ispell--call-enchant-lsmod, it did = need to use with-current-buffer, so I have installed a patch that restores = the use of with-current-buffer; apologies for getting that wrong first time= .

In fact, this change= is not sufficient to fix the original problem, because the enchant program= outputs the same warning when a provider module cannot be loaded. In this = case, stderr is added to the list of suggested words. Again, I believe Ench= ant is correct to output a warning, and again, I believe Emacs is wrong to = amalgamate stderr and stdout.

I attach three patches that do the following:

1. Simplify ispell-call-process{,-region} = by factoring out the macro ispell-with-safe-default-directory.

2. I also = found that ispell-check-version can be simplified slightly: aspell has acce= pted -vv since 2004, so use it always.
3. When spell-checking, collect onl= y standard output. This leaves some spell-checker-specific calls to ispell-= call-process to collect stderr as well, which as far as I can tell is neede= d in only one case, ispell-find-hunspell-dictionaries; but it doesn't h= urt to leave the rest unchanged. I have tested this patch with all supporte= d spellcheckers (ispell, aspell, hunspell, enchant).
--000000000000700a9205b326b964-- --000000000000700a9405b326b966 Content-Type: text/x-patch; charset="US-ASCII"; name="0002-Factor-out-some-common-code-in-ispell.el.patch" Content-Disposition: attachment; filename="0002-Factor-out-some-common-code-in-ispell.el.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kh12rjj31 RnJvbSAxYWE2YzlmNWU3Y2U4OWY5NDQwYTJhNWI0YzU5MWU2NWM4YjRlNWEwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSZXViZW4gVGhvbWFzIDxycnRAc2MzZC5vcmc+CkRhdGU6IE1v biwgMiBOb3YgMjAyMCAyMTo0NTo0MCArMDAwMApTdWJqZWN0OiBbUEFUQ0ggMi8zXSBGYWN0b3Ig b3V0IHNvbWUgY29tbW9uIGNvZGUgaW4gaXNwZWxsLmVsCgoqIGxpc3AvdGV4dG1vZGVzL2lzcGVs bC5lbCAoaXNwZWxsLXdpdGgtc2FmZS1kZWZhdWx0LWRpcmVjdG9yeSk6IEFkZAogIG1hY3JvLgog IChpc3BlbGwtY2FsbC1wcm9jZXNzLCBpc3BlbGwtY2FsbC1wcm9jZXNzLXJlZ2lvbik6IFVzZSBp dC4KLS0tCiBsaXNwL3RleHRtb2Rlcy9pc3BlbGwuZWwgfCAyMSArKysrKysrKysrKysrLS0tLS0t LS0KIDEgZmlsZSBjaGFuZ2VkLCAxMyBpbnNlcnRpb25zKCspLCA4IGRlbGV0aW9ucygtKQoKZGlm ZiAtLWdpdCBhL2xpc3AvdGV4dG1vZGVzL2lzcGVsbC5lbCBiL2xpc3AvdGV4dG1vZGVzL2lzcGVs bC5lbAppbmRleCA5ZTU2OTIzZDYwLi40OWRhM2QxZWQ0IDEwMDY0NAotLS0gYS9saXNwL3RleHRt b2Rlcy9pc3BlbGwuZWwKKysrIGIvbGlzcC90ZXh0bW9kZXMvaXNwZWxsLmVsCkBAIC03NjksMTgg Kzc2OSwyMyBAQCBpc3BlbGwtY2hlY2stdmVyc2lvbgogCSAgICAoc2V0cSBpc3BlbGwtcmVhbGx5 LWh1bnNwZWxsIG5pbCkpKSkpKQogICAgIHJlc3VsdCkpCiAKKyhkZWZtYWNybyBpc3BlbGwtd2l0 aC1zYWZlLWRlZmF1bHQtZGlyZWN0b3J5ICgmcmVzdCBib2R5KQorICAiRXhlY3V0ZSB0aGUgZm9y bXMgaW4gQk9EWSB3aXRoIGEgcmVhc29uYWJsZQorYGRlZmF1bHQtZGlyZWN0b3J5Jy4iCisgIChk ZWNsYXJlIChpbmRlbnQgMCkgKGRlYnVnIHQpKQorICBgKGxldCAoKGRlZmF1bHQtZGlyZWN0b3J5 IGRlZmF1bHQtZGlyZWN0b3J5KSkKKyAgICAgKHVubGVzcyAoZmlsZS1hY2Nlc3NpYmxlLWRpcmVj dG9yeS1wIGRlZmF1bHQtZGlyZWN0b3J5KQorICAgICAgIChzZXRxIGRlZmF1bHQtZGlyZWN0b3J5 IChleHBhbmQtZmlsZS1uYW1lICJ+LyIpKSkKKyAgICAgLEBib2R5KSkKKwogKGRlZnVuIGlzcGVs bC1jYWxsLXByb2Nlc3MgKCZyZXN0IGFyZ3MpCi0gICJMaWtlIGBjYWxsLXByb2Nlc3MnIGJ1dCBk ZWZlbmQgYWdhaW5zdCBiYWQgYGRlZmF1bHQtZGlyZWN0b3J5Jy4iCi0gIChsZXQgKChkZWZhdWx0 LWRpcmVjdG9yeSBkZWZhdWx0LWRpcmVjdG9yeSkpCi0gICAgKHVubGVzcyAoZmlsZS1hY2Nlc3Np YmxlLWRpcmVjdG9yeS1wIGRlZmF1bHQtZGlyZWN0b3J5KQotICAgICAgKHNldHEgZGVmYXVsdC1k aXJlY3RvcnkgKGV4cGFuZC1maWxlLW5hbWUgIn4vIikpKQorICAiTGlrZSBgY2FsbC1wcm9jZXNz JywgYnV0IGRlZmVuZCBhZ2FpbnN0IGJhZCBgZGVmYXVsdC1kaXJlY3RvcnknLiIKKyAgKGlzcGVs bC13aXRoLXNhZmUtZGVmYXVsdC1kaXJlY3RvcnkKICAgICAoYXBwbHkgJ2NhbGwtcHJvY2VzcyBh cmdzKSkpCiAKIChkZWZ1biBpc3BlbGwtY2FsbC1wcm9jZXNzLXJlZ2lvbiAoJnJlc3QgYXJncykK LSAgIkxpa2UgYGNhbGwtcHJvY2Vzcy1yZWdpb24nIGJ1dCBkZWZlbmQgYWdhaW5zdCBiYWQgYGRl ZmF1bHQtZGlyZWN0b3J5Jy4iCi0gIChsZXQgKChkZWZhdWx0LWRpcmVjdG9yeSBkZWZhdWx0LWRp cmVjdG9yeSkpCi0gICAgKHVubGVzcyAoZmlsZS1hY2Nlc3NpYmxlLWRpcmVjdG9yeS1wIGRlZmF1 bHQtZGlyZWN0b3J5KQotICAgICAgKHNldHEgZGVmYXVsdC1kaXJlY3RvcnkgKGV4cGFuZC1maWxl LW5hbWUgIn4vIikpKQorICAiTGlrZSBgY2FsbC1wcm9jZXNzLXJlZ2lvbicsIGJ1dCBkZWZlbmQg YWdhaW5zdCBiYWQgYGRlZmF1bHQtZGlyZWN0b3J5Jy4iCisgIChpc3BlbGwtd2l0aC1zYWZlLWRl ZmF1bHQtZGlyZWN0b3J5CiAgICAgKGFwcGx5ICdjYWxsLXByb2Nlc3MtcmVnaW9uIGFyZ3MpKSkK IAogKGRlZnZhciBpc3BlbGwtZGVidWctYnVmZmVyKQotLSAKMi4yNS4xCgo= --000000000000700a9405b326b966 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Simplify-ispell-check-version-s-use-of-vv-flag.patch" Content-Disposition: attachment; filename="0001-Simplify-ispell-check-version-s-use-of-vv-flag.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kh12rjis0 RnJvbSBjODNmZmNiZTFiYTk1MGI5MjcwYmNkZTU2ZDExN2MyYzUwZTM1MTEyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSZXViZW4gVGhvbWFzIDxycnRAc2MzZC5vcmc+CkRhdGU6IE1v biwgMiBOb3YgMjAyMCAyMTo0MTowNSArMDAwMApTdWJqZWN0OiBbUEFUQ0ggMS8zXSA9P1VURi04 P3E/U2ltcGxpZnk9MjBpc3BlbGwtY2hlY2stdmVyc2lvbj1FMj04MD05OXM/PQogPT9VVEYtOD9x Pz0yMHVzZT0yMG9mPTIwLXZ2PTIwZmxhZz89Ck1JTUUtVmVyc2lvbjogMS4wCkNvbnRlbnQtVHlw ZTogdGV4dC9wbGFpbjsgY2hhcnNldD1VVEYtOApDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA4 Yml0CgoqIGxpc3AvdGV4dG1vZGVzL2lzcGVsbC5lbCAoaXNwZWxsLWNoZWNrLXZlcnNpb24pOiBB bGwgc3VwcG9ydGVkIHNwZWxsCmNoZWNrZXIgcHJvZ3JhbXMgYWNjZXB0IC12diwgaW5jbHVkaW5n IGFzcGVsbCBmb3IgbWFueSB5ZWFycywgc28gdXNlCml0LgotLS0KIGxpc3AvdGV4dG1vZGVzL2lz cGVsbC5lbCB8IDQgKy0tLQogMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCspLCAzIGRlbGV0 aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpc3AvdGV4dG1vZGVzL2lzcGVsbC5lbCBiL2xpc3AvdGV4 dG1vZGVzL2lzcGVsbC5lbAppbmRleCBkYTNjM2Y0ZDZmLi45ZTU2OTIzZDYwIDEwMDY0NAotLS0g YS9saXNwL3RleHRtb2Rlcy9pc3BlbGwuZWwKKysrIGIvbGlzcC90ZXh0bW9kZXMvaXNwZWxsLmVs CkBAIC02ODQsMTMgKzY4NCwxMSBAQCBpc3BlbGwtY2hlY2stdmVyc2lvbgogICAgICh3aXRoLXRl bXAtYnVmZmVyCiAgICAgICAoc2V0cSBzdGF0dXMgKGlzcGVsbC1jYWxsLXByb2Nlc3MKIAkJICAg IGlzcGVsbC1wcm9ncmFtLW5hbWUgbmlsIHQgbmlsCi0JCSAgICA7OyBhc3BlbGwgZG9lc24ndCBh Y2NlcHQgdGhlIC12diBzd2l0Y2guCiAJCSAgICAobGV0ICgoY2FzZS1mb2xkLXNlYXJjaAogCQkJ ICAgKG1lbXEgc3lzdGVtLXR5cGUgJyhtcy1kb3Mgd2luZG93cy1udCkpKQogCQkJICAoc3BlbGxl cgogCQkJICAgKGZpbGUtbmFtZS1ub25kaXJlY3RvcnkgaXNwZWxsLXByb2dyYW0tbmFtZSkpKQot CQkgICAgICA7OyBBc3N1bWUgYW55dGhpbmcgdGhhdCBpc24ndCBgYXNwZWxsJyBpcyBJc3BlbGwu Ci0JCSAgICAgIChpZiAoc3RyaW5nLW1hdGNoICJcXGBhc3BlbGwiIHNwZWxsZXIpICItdiIgIi12 diIpKSkpCisJCSAgICAgICItdnYiKSkpCiAgICAgICAoZ290by1jaGFyIChwb2ludC1taW4pKQog ICAgICAgKGlmIGludGVyYWN0aXZlcAogCSAgOzsgUmVwb3J0IHZlcnNpb24gaW5mb3JtYXRpb24g b2YgaXNwZWxsCi0tIAoyLjI1LjEKCg== --000000000000700a9405b326b966 Content-Type: text/x-patch; charset="US-ASCII"; name="0003-Prevent-ispell-being-confused-by-spellchecker-output.patch" Content-Disposition: attachment; filename="0003-Prevent-ispell-being-confused-by-spellchecker-output.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_kh12rjj42 RnJvbSA1ZDc3MjE3NzUzNmRjZmVkNjA3MTU5ODAyZWVhZGNkMjJlYWIxOTY5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBSZXViZW4gVGhvbWFzIDxycnRAc2MzZC5vcmc+CkRhdGU6IE1v biwgMiBOb3YgMjAyMCAyMTo0NTo1MiArMDAwMApTdWJqZWN0OiBbUEFUQ0ggMy8zXSBQcmV2ZW50 IGBpc3BlbGwnIGJlaW5nIGNvbmZ1c2VkIGJ5IHNwZWxsY2hlY2tlciBvdXRwdXQgb24KIHN0ZGVy cgoKKiBsaXNwL3RleHRtb2Rlcy9pc3BlbGwuZWwgKGlzcGVsbC1zZW5kLXN0cmluZywgaXNwZWxs LWxvb2t1cC13b3Jkcyk6CkNhcHR1cmUgb25seSBzdGRvdXQuIFRoaXMgYXZvaWRzIHdhcm5pbmcg bWVzc2FnZXMsIGUuZy4gZnJvbSBFbmNoYW50LApmcm9tIGJlaW5nIGludGVycHJldGVkIGFzIG91 dHB1dCBmcm9tIHRoZSBzcGVsbC1jaGVja2VyIHByb2Nlc3MuCi0tLQogbGlzcC90ZXh0bW9kZXMv aXNwZWxsLmVsIHwgNCArKy0tCiAxIGZpbGUgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAyIGRl bGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2xpc3AvdGV4dG1vZGVzL2lzcGVsbC5lbCBiL2xpc3Av dGV4dG1vZGVzL2lzcGVsbC5lbAppbmRleCA0OWRhM2QxZWQ0Li44ZDkwY2FiNjUzIDEwMDY0NAot LS0gYS9saXNwL3RleHRtb2Rlcy9pc3BlbGwuZWwKKysrIGIvbGlzcC90ZXh0bW9kZXMvaXNwZWxs LmVsCkBAIC0xODYxLDcgKzE4NjEsNyBAQCBpc3BlbGwtc2VuZC1zdHJpbmcKIAkJICAgIChhcHBs eSAnaXNwZWxsLWNhbGwtcHJvY2Vzcy1yZWdpb24KIAkJCSAgIChwb2ludC1taW4pIChwb2ludC1t YXgpCiAJCQkgICBpc3BlbGwtcHJvZ3JhbS1uYW1lIG5pbAotCQkJICAgb3V0cHV0LWJ1ZiBuaWwK KwkJCSAgICcob3V0cHV0LWJ1ZiBuaWwpIG5pbAogCQkJICAgIi1hIgogCQkJICAgOzsgaHVuc3Bl bGwgLW0gb3B0aW9uIG1lYW5zIHNvbWV0aGluZyBkaWZmZXJlbnQKIAkJCSAgIChpZiBpc3BlbGwt cmVhbGx5LWh1bnNwZWxsICIiICItbSIpCkBAIC0yNTY2LDcgKzI1NjYsNyBAQCBpc3BlbGwtbG9v a3VwLXdvcmRzCiAgICAgICAgICh3aGlsZSAoc2VhcmNoLWJhY2t3YXJkICIqIiBuaWwgdCkgKGlu c2VydCAiLiIpKQogICAgICAgICAoc2V0cSB3b3JkIChidWZmZXItc3RyaW5nKSkKICAgICAgICAg KGVyYXNlLWJ1ZmZlcikpCi0gICAgICAoc2V0cSBzdGF0dXMgKGFwcGx5ICdpc3BlbGwtY2FsbC1w cm9jZXNzIHByb2cgbmlsIHQgbmlsCisgICAgICAoc2V0cSBzdGF0dXMgKGFwcGx5ICdpc3BlbGwt Y2FsbC1wcm9jZXNzIHByb2cgbmlsICcodCBuaWwpIG5pbAogICAgICAgICAgICAgICAgICAgICAg ICAgICAobmNvbmMgKGlmIChhbmQgYXJncyAoPiAobGVuZ3RoIGFyZ3MpIDApKQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChsaXN0IGFyZ3MpCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIChpZiBsb29rLXAgbmlsCi0tIAoyLjI1LjEKCg== --000000000000700a9405b326b966-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 11:45:19 2020 Received: (at 44318) by debbugs.gnu.org; 3 Nov 2020 16:45:19 +0000 Received: from localhost ([127.0.0.1]:46225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZzQs-0005XQ-RG for submit@debbugs.gnu.org; Tue, 03 Nov 2020 11:45:19 -0500 Received: from eggs.gnu.org ([209.51.188.92]:46106) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZzQr-0005XC-Fs for 44318@debbugs.gnu.org; Tue, 03 Nov 2020 11:45:17 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46991) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kZzQm-0002Bk-1s; Tue, 03 Nov 2020 11:45:12 -0500 Received: from [176.228.60.248] (port=2981 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1kZzQl-0003C9-GY; Tue, 03 Nov 2020 11:45:11 -0500 Date: Tue, 03 Nov 2020 18:45:02 +0200 Message-Id: <83a6vycru9.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-Reply-To: (message from Reuben Thomas on Mon, 2 Nov 2020 21:49:33 +0000) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, dinkonin@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Reuben Thomas > Date: Mon, 2 Nov 2020 21:49:33 +0000 > Cc: dinkonin , 44318@debbugs.gnu.org > > 1. Simplify ispell-call-process{,-region} by factoring out the macro ispell-with-safe-default-directory. > > 2. I also found that ispell-check-version can be simplified slightly: aspell has accepted -vv since 2004, so use > it always. > 3. When spell-checking, collect only standard output. This leaves some spell-checker-specific calls to > ispell-call-process to collect stderr as well, which as far as I can tell is needed in only one case, > ispell-find-hunspell-dictionaries; but it doesn't hurt to leave the rest unchanged. I have tested this patch with > all supported spellcheckers (ispell, aspell, hunspell, enchant). I'm okay with the first 2, but I'm less comfortable with the 3rd one. It is wrong to assume that nothing but warnings come through stderr: for example "hunspell -D" emits the important information to stderr, at least on my system. It could be that we don't currently use the 2 functions you suggest to change for such cases, but I think ignoring stderr in some calls and not the others is a slippery slope of confusion and subtle bugs. 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? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 12:06:49 2020 Received: (at 44318) by debbugs.gnu.org; 3 Nov 2020 17:06:49 +0000 Received: from localhost ([127.0.0.1]:46276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZzlh-00066E-Bm for submit@debbugs.gnu.org; Tue, 03 Nov 2020 12:06:49 -0500 Received: from mail-oo1-f47.google.com ([209.85.161.47]:40882) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kZzlf-000661-JD for 44318@debbugs.gnu.org; Tue, 03 Nov 2020 12:06:48 -0500 Received: by mail-oo1-f47.google.com with SMTP id p73so4368588oop.7 for <44318@debbugs.gnu.org>; Tue, 03 Nov 2020 09:06:47 -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=Tzq1pNLh2NXgjEwrvj289IwcWF3Pb96cZZgKvDFvJEw=; b=AvQ2dvIwGkSlf7HaOGJNNPII2gZvAnzCBVNRLXYLw+bW39qtj9KtLnK4lOdxgxWSL0 sOQJhy/Nnz1cx8fCZHs9KefIhoJHT01+JlTzgKVb/FG8XonI1TF+jPaMh6Z795Qj+D2B Sw2EidUpEHMJekDzaGh8wBrvYB5ZHf80ledqw= 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=Tzq1pNLh2NXgjEwrvj289IwcWF3Pb96cZZgKvDFvJEw=; b=WKd5L7t8MfYtdxALutUZnIkZsJBGYrrfMjs0tDzyIZkHOZm71d2WEXkkBz0AZw9gUa ktgG2U7x9S/glTt6BQHD46yGFZONkqRHouT51YXvs5R6ABXifwfcp8Q9JApIbQjANjRq KLsW5NklYR4Z8UllyjKVTAaY/sjzOBzgbp9XcSRBK1IYm0ScH+HtF3TaDVP18viEQgr7 TZBPOECE9BAuU9uUiCCgF+UOPo6bz4kDZCzyZCkIxtv2LVTWufY8UPiLY9BkEKWichhT cImTMkmD4gCOOkvdcmT/YHRbY6GiFpX2cGGcvNxUubOMIlhNlkuOJh3UQq3ZZ7CzN1xT L01g== X-Gm-Message-State: AOAM5329/gA484fvIqkqoT2Bd7fIvWMrNI7VW4+Cd2JJ7X5syUHG9JV1 LUi0I6OeqtUly1/6Wqvvg5vHG1eUoa0RbPUrqK4y1g== X-Google-Smtp-Source: ABdhPJy9tLQwrxyQT7Bi3RPKBqi3kIS9fM/huF4VdCeILX81i0/UVXIiXt6sY2f+cEtMV4PI5bP4QrTvg3MuZdjql3w= X-Received: by 2002:a4a:b503:: with SMTP id r3mr15911289ooo.28.1604423201935; Tue, 03 Nov 2020 09:06:41 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: <83a6vycru9.fsf@gnu.org> From: Reuben Thomas Date: Tue, 3 Nov 2020 17:06:30 +0000 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000005798b05b336e331" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: 44318@debbugs.gnu.org, dinkonin X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000005798b05b336e331 Content-Type: text/plain; charset="UTF-8" [Apologies Eli, re-sending to list rather than just you.] On Tue, 3 Nov 2020 at 16:45, Eli Zaretskii wrote: > > I'm okay with the first 2, Great, I'll install those! but I'm less comfortable with the 3rd one. > It is wrong to assume that nothing but warnings come through stderr: > for example "hunspell -D" emits the important information to stderr, > at least on my system. Exactly, I found this while testing a more ambitious patch that never collected stderr (and indeed versions of Enchant until last night's release of 2.2.13 printed their --version output on stderr). Hence, all of those uses still collect stderr. It could be that we don't currently use the 2 > functions you suggest to change for such cases, but I think ignoring > stderr in some calls and not the others is a slippery slope of > confusion and subtle bugs. The two functions I changed implement a long-running communication with the spellchecker using the ispell protocol, notionally over a pipe. There's no reason to mix two streams, and in any case that would only work fortuitously, since the spellchecker doesn't know how those streams will be combined. In other words, a source of confusion and subtle bugs. Fortunately, none of the current spellcheckers we support tries to do this. > 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. -- https://rrt.sc3d.org --00000000000005798b05b336e331 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
[A= pologies Eli, re-sending to list rather than just you.]

On Tue, 3 Nov 2020 at 16:45, Eli Zaretskii <eliz@gnu.org> wrote:

I'm okay with the first 2,

Great, I'll install those!

but I'm le= ss comfortable with the 3rd one.
It is wrong to assume that nothing but warnings come through stderr:
for example "hunspell -D" emits the important information to stde= rr,
at least on my system.=C2=A0

Exactly, I found this while testing a more ambitious patch that never collected=20 stderr (and indeed versions of Enchant until last night's release of=20 2.2.13 printed their --version output on stderr).
<= br>
Hence, all of those uses still collect stderr.=

It could be that we don't currently use the 2
functions you suggest to change for such cases, but I think ignoring
stderr in some calls and not the others is a slippery slope of
confusion and subtle bugs.

The two functions I changed implement a long-running communication with the spellchecker using the ispell protocol, notionally over a pipe. There'= s no reason to mix two streams, and in any case that would only work=20 fortuitously, since the spellchecker doesn't know how those streams wil= l be combined. In other words, a source of confusion and subtle bugs.
<= div style=3D"font-family:arial,helvetica,sans-serif;font-size:small" class= =3D"gmail_default">
Fortunately, none of the cu= rrent spellcheckers we support tries to do this.
=C2=A0
=C2=A0 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 "enchan= t"=20 program outputs warnings on stderr, just like enchant-lsmod. This is=20 interpreted by Emacs as additions to the suggestions or corrections=20 list, which is clearly wrong.

--
--00000000000005798b05b336e331-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 12:20:17 2020 Received: (at 44318) by debbugs.gnu.org; 3 Nov 2020 17:20:17 +0000 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 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 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) MIME-Version: 1.0 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> In-Reply-To: <835z6mcqyg.fsf@gnu.org> From: Reuben Thomas Date: Tue, 3 Nov 2020 17:19:56 +0000 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000009186405b33713f1" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: dinkonin , 44318@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --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-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 12:32:13 2020 Received: (at 44318) by debbugs.gnu.org; 3 Nov 2020 17:32:13 +0000 Received: from localhost ([127.0.0.1]:46320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka0AH-0006nw-7I for submit@debbugs.gnu.org; Tue, 03 Nov 2020 12:32:13 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka0AF-0006nj-7S for 44318@debbugs.gnu.org; Tue, 03 Nov 2020 12:32:11 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:48209) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ka0A9-0007fg-P2; Tue, 03 Nov 2020 12:32:05 -0500 Received: from [176.228.60.248] (port=2107 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ka0A8-0007cj-J4; Tue, 03 Nov 2020 12:32:05 -0500 Date: Tue, 03 Nov 2020 19:31:57 +0200 Message-Id: <834km6cpo2.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-Reply-To: (message from Reuben Thomas on Tue, 3 Nov 2020 17:19:56 +0000) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318 Cc: dinkonin@gmail.com, 44318@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Reuben Thomas > Date: Tue, 3 Nov 2020 17:19:56 +0000 > Cc: 44318@debbugs.gnu.org, dinkonin > > 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.) > A longer-term solution would be to drop support for spellcheckers other than Enchant. 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. Not having to deal with idiosyncratic behavior of several spellers is an advantage, but I think the risk of being left without an actively maintained spell-checking engine is so serious that it tramps that advantage many times over. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 13:27:51 2020 Received: (at 44318) by debbugs.gnu.org; 3 Nov 2020 18:27:51 +0000 Received: from localhost ([127.0.0.1]:46384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka127-0008CE-Cg for submit@debbugs.gnu.org; Tue, 03 Nov 2020 13:27:51 -0500 Received: from mail-oi1-f182.google.com ([209.85.167.182]:32818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka125-0008By-I0 for 44318@debbugs.gnu.org; Tue, 03 Nov 2020 13:27:50 -0500 Received: by mail-oi1-f182.google.com with SMTP id s21so19396641oij.0 for <44318@debbugs.gnu.org>; Tue, 03 Nov 2020 10:27:49 -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=dePaqW1N2dOd18vRGzqE/g7n9iAqVophebwXdKffoUI=; b=Lqh1HJEgKjVmFEwdegi/15OrIFWajJjsb/xvgR1RuCS0/J3pN1MUmLESLp0Vb6kGrt GqPgdlWjdgwkKHewkgrxlf/oF36oNAU+R6ZPpsDL2N9b3dtHA93MQobpMVjR5qABariw TOC6BMbNk5cqnPytLVTkyv9bcJNz/Fc2A63zM= 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=dePaqW1N2dOd18vRGzqE/g7n9iAqVophebwXdKffoUI=; b=sIx4wtuzTDvH5FUWoQSW/griOIxbogFiTwAvVTfFXWLNo7k+4wbFCyDt3fz5pje1OR R1XRBTmMNwnesyQy+7KE0K86ZDmuWZHc/ZxntUSWbOd9vrzEkzHKCGIS6MfRK81HqKpb WgY+JSvYrZU5WrsVf23MAVqta5a6r2lkggc9JVtKIEqXB8kIqvz3LJQetzmDDrDUXnWR FB0fj3bue8yWElx2attUQejsgULSxa/+AguRrULAXIKQvSiobq20NJLZpvZ2t0qcpDmQ nCfmpKivofc+6akKeTzmHLOG84Kubrdd1fK1mWZk5qsEGuWkrFv3rvVZtexijex7Lb+e LRKg== X-Gm-Message-State: AOAM531iv+yuKndF26a4SrbDyl5fH9bC8CK/ILXQqfd2prqXn/Ms+WTN I8vDmaASUhZ2KmtLEkoMFT67KubR54nUrSugsXmGiA== X-Google-Smtp-Source: ABdhPJyeGaCS3khDeRa/wT3jM9nb10rnnkAcvpM3z+VfIxbCO8MYqGpbqdi6Udp+ZCVOqtf/7bE7el5E1UBT4b2lwi8= X-Received: by 2002:aca:ecd4:: with SMTP id k203mr271242oih.179.1604428063713; Tue, 03 Nov 2020 10:27:43 -0800 (PST) MIME-Version: 1.0 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> <834km6cpo2.fsf@gnu.org> In-Reply-To: <834km6cpo2.fsf@gnu.org> From: Reuben Thomas Date: Tue, 3 Nov 2020 18:27:32 +0000 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/alternative; boundary="000000000000ce410805b338046f" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: dinkonin , 44318@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000ce410805b338046f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 3 Nov 2020 at 17:32, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Tue, 3 Nov 2020 17:19:56 +0000 > > Cc: 44318@debbugs.gnu.org, dinkonin > > > > 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 o= f > 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=E2=80=94it doesn't seem to have been a serious proble= m, 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. --=20 https://rrt.sc3d.org --000000000000ce410805b338046f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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@d= ebbugs.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 cli= ent of a pipe protocol like this to combine two
> streams (which cannot safely make sense).

It worked until now.=C2=A0 Enchant is the new kid on the block, so I
respectfully request that it behaves itself.=C2=A0 Yes, it probably means it should suppress the warning when invoked with -a, but I see no
problem with that.=C2=A0 (You could even consider suppressing the warning entirely, and only emitting it when some feature which requires the
problematic trait is requested.=C2=A0 But I won't tell you how to devel= op
Enchant's UI.)

I'= ;ll leave it for now=E2=80=94it doesn't seem to have been a serious pro= blem, and the warnings are only emitted for an incorrectly-installed Enchan= t, 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; l= et alone the option of forking/maintaining free software, which is one of i= ts 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 towa= rds making it more palatable in your terms too.

--
--000000000000ce410805b338046f-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 13:50:26 2020 Received: (at 44318) by debbugs.gnu.org; 3 Nov 2020 18:50:26 +0000 Received: from localhost ([127.0.0.1]:46405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka1Ny-0000KD-9z for submit@debbugs.gnu.org; Tue, 03 Nov 2020 13:50:26 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka1Nv-0000Jx-OU for 44318@debbugs.gnu.org; Tue, 03 Nov 2020 13:50:24 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49657) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ka1No-0001Ro-R6; Tue, 03 Nov 2020 13:50:18 -0500 Received: from [176.228.60.248] (port=2985 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ka1No-0005Vo-17; Tue, 03 Nov 2020 13:50:16 -0500 Date: Tue, 03 Nov 2020 20:50:08 +0200 Message-Id: <83zh3yb7hb.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-Reply-To: (message from Reuben Thomas on Tue, 3 Nov 2020 18:27:32 +0000) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend 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> <834km6cpo2.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318 Cc: dinkonin@gmail.com, 44318@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Reuben Thomas > Date: Tue, 3 Nov 2020 18:27:32 +0000 > Cc: 44318@debbugs.gnu.org, dinkonin > > 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. We are miscommunicating. My point is that if Emacs will depend on Enchant and won't be able to use the existing spellers without Enchant being in-between, then we will be in a dire situation if Enchant stops being developed and bit-rots. By contrast, with the current code, we can always tell users to use aspell/hunspell directly. From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 13:54:13 2020 Received: (at 44318) by debbugs.gnu.org; 3 Nov 2020 18:54:13 +0000 Received: from localhost ([127.0.0.1]:46413 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka1Rd-0000Q9-57 for submit@debbugs.gnu.org; Tue, 03 Nov 2020 13:54:13 -0500 Received: from mail-ot1-f48.google.com ([209.85.210.48]:35539) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka1Rb-0000Pv-UC for 44318@debbugs.gnu.org; Tue, 03 Nov 2020 13:54:12 -0500 Received: by mail-ot1-f48.google.com with SMTP id n11so16979554ota.2 for <44318@debbugs.gnu.org>; Tue, 03 Nov 2020 10:54:11 -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=MPxlXeW0mr5kHFvFU9KFPjfcRTRCTyxihtVX9fulET8=; b=Z7Uq3Iw2x4oiaZNh2i3UGrnREZpHShTMmJMB5kYS70V4ZYU2wysMXnfTtDY63IOW6o D82GhZoWK8sdtqizq6Z6RwQDyIbztqIP2L+uokEcqAilVpieRhl/zIdGIbzaJ8s4GU37 5f4Y6ZkT9DO0etV4q2DxZEWdJ/TMNbV8APmfU= 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=MPxlXeW0mr5kHFvFU9KFPjfcRTRCTyxihtVX9fulET8=; b=GygJZfB2wqeYFrqyfpmgBr+s74jSprv9p4MeChlsuyVHJN6U1qTva3wNXzkYNbfGqr Z1p5ht4GJGskmlmZi+OfDo+gvPlqBHwtu2chvoGjz2J5l509qR3hjzBhJhYXWIkZB33W OgyWIrauyelTV1LTevEWl3qThIljiY1bgCv/TbdkLsWI4e0ozBY6jLKaRvfutZTE1Uay E50saaYg3c+zvDCtVYCjG/Pppj7gJqNeJvNthP2Q3DnyS21KGidJPxoZkey7fFW5VuxP 2UTz0hqabQfQVq3x9KKIY6LOa5P7wo0+RCRZxh+W+s2XCi1g3tfZvYaqtq+q/S2oKP37 EOPg== X-Gm-Message-State: AOAM532xRfj2UBEKJvY3G2DmJ/Hj2zHSrQl6Ux43Bi2B5JQn5gvV7zi5 I3GI1hOQQVjzgEWdWGpD3KUynPlKXMp/4oRCegTLWg== X-Google-Smtp-Source: ABdhPJwWgRnu/+6YQEFISx3gwh+J5yieX3fJhMTZ/vksY9bjXUbBI21ilCX5BynfsEm2T6L842ZGw2VOkYA7XNt58Zo= X-Received: by 2002:a9d:6c4e:: with SMTP id g14mr1931765otq.120.1604429645956; Tue, 03 Nov 2020 10:54:05 -0800 (PST) MIME-Version: 1.0 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> <834km6cpo2.fsf@gnu.org> <83zh3yb7hb.fsf@gnu.org> In-Reply-To: <83zh3yb7hb.fsf@gnu.org> From: Reuben Thomas Date: Tue, 3 Nov 2020 18:53:54 +0000 Message-ID: Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000001dae9c05b3386352" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 44318 Cc: dinkonin , 44318@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000001dae9c05b3386352 Content-Type: text/plain; charset="UTF-8" On Tue, 3 Nov 2020 at 18:50, Eli Zaretskii wrote: > > From: Reuben Thomas > > Date: Tue, 3 Nov 2020 18:27:32 +0000 > > Cc: 44318@debbugs.gnu.org, dinkonin > > > > 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. > > We are miscommunicating. My point is that if Emacs will depend on > Enchant and won't be able to use the existing spellers without Enchant > being in-between, then we will be in a dire situation if Enchant stops > being developed and bit-rots. By contrast, with the current code, we > can always tell users to use aspell/hunspell directly. > What I was trying to say is that it would be very easy to re-add support for the other spell-checkers, since they and Enchant operate in the same way, and they would not have changed in the mean time. There is little to rot in Enchant, I intend to reduce that amount, and in the end it should be less effort to maintain Enchant than to maintain multiple back-ends in ispell.el. -- https://rrt.sc3d.org --0000000000001dae9c05b3386352 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 3 Nov 2020 at 18:50, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Reuben Thomas <rrt@sc3d.org>
> Date: Tue, 3 Nov 2020 18:27:32 +0000
> Cc: 44318@d= ebbugs.gnu.org, dinkonin <dinkonin@gmail.com>
>
>=C2=A0 I think it would be wrong for Emacs to do that, as that would pu= t all
>=C2=A0 the eggs in a single basket, something that is not safe in Free<= br> >=C2=A0 Software world, where packages become unmaintained outside of ou= r
>=C2=A0 control.
>
> I don't understand this: Emacs, to this day, is happy to import la= rge 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-chec= kers, the cost of switching is low. For
> myself, I'd be more concerned with bugs or missing functionality i= n Enchant as a reason to be cautious (i.e.
> I would want to see a phased transition) than about the long-term pros= pects.

We are miscommunicating.=C2=A0 My point is that if Emacs will depend on
Enchant and won't be able to use the existing spellers without Enchant<= br> being in-between, then we will be in a dire situation if Enchant stops
being developed and bit-rots.=C2=A0 By contrast, with the current code, we<= br> can always tell users to use aspell/hunspell directly.

What I was trying= to say is that it would be very easy to re-add support for the other spell= -checkers, since they and Enchant operate in the same way, and they would n= ot have changed in the mean time. There is little to rot in Enchant, I inte= nd to reduce that amount, and in the end it should be less effort to mainta= in Enchant than to maintain multiple back-ends in ispell.el.

--
--0000000000001dae9c05b3386352-- From debbugs-submit-bounces@debbugs.gnu.org Tue Nov 03 14:39:54 2020 Received: (at 44318) by debbugs.gnu.org; 3 Nov 2020 19:39:54 +0000 Received: from localhost ([127.0.0.1]:46501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka29q-0003kk-Ie for submit@debbugs.gnu.org; Tue, 03 Nov 2020 14:39:54 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ka29o-0003kV-Oo for 44318@debbugs.gnu.org; Tue, 03 Nov 2020 14:39:53 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50403) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ka29j-00082p-9g; Tue, 03 Nov 2020 14:39:47 -0500 Received: from [176.228.60.248] (port=2052 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ka29i-0000Ic-Jq; Tue, 03 Nov 2020 14:39:47 -0500 Date: Tue, 03 Nov 2020 21:39:40 +0200 Message-Id: <83wnz2b56r.fsf@gnu.org> From: Eli Zaretskii To: Reuben Thomas In-Reply-To: (message from Reuben Thomas on Tue, 3 Nov 2020 18:53:54 +0000) Subject: Re: bug#44318: 28.0.50; Problem with ispell/flyspell and ""enchant"" backend 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> <834km6cpo2.fsf@gnu.org> <83zh3yb7hb.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 44318 Cc: dinkonin@gmail.com, 44318@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Reuben Thomas > Date: Tue, 3 Nov 2020 18:53:54 +0000 > Cc: 44318@debbugs.gnu.org, dinkonin > > We are miscommunicating. My point is that if Emacs will depend on > Enchant and won't be able to use the existing spellers without Enchant > being in-between, then we will be in a dire situation if Enchant stops > being developed and bit-rots. By contrast, with the current code, we > can always tell users to use aspell/hunspell directly. > > What I was trying to say is that it would be very easy to re-add support for the other spell-checkers, since > they and Enchant operate in the same way, and they would not have changed in the mean time. If we switch to supporting only Enchant, the compatibility will soon disappear. And re-adding back deleted code is just waste of resources. So I still think this is not a good idea, sorry. > in the end it should be less effort to maintain Enchant than to > maintain multiple back-ends in ispell.el. That's an advantage, indeed, but as I said before, the downsides overwhelm it. From unknown Sat Sep 20 18:57:54 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 02 Dec 2020 12:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator