From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Reuben Thomas Newsgroups: gmane.emacs.bugs Subject: bug#17742: Acknowledgement (Support for enchant?) Date: Mon, 19 Dec 2016 22:04:55 +0000 Message-ID: References: <834m2hjbmr.fsf@gnu.org> <83bmwfbxaf.fsf@gnu.org> <837f73bqwv.fsf@gnu.org> <838trb6h7s.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114f5c2e2910d405440a1c3f X-Trace: blaine.gmane.org 1482185339 11524 195.159.176.226 (19 Dec 2016 22:08:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Dec 2016 22:08:59 +0000 (UTC) Cc: 17742@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Dec 19 23:08:55 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJ675-0002J4-0x for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Dec 2016 23:08:55 +0100 Original-Received: from localhost ([::1]:48000 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJ679-0001O4-Fk for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Dec 2016 17:08:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45272) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJ64N-00074h-2l for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2016 17:06:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cJ64I-0001x7-PI for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2016 17:06:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60865) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cJ64I-0001wp-Kz for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2016 17:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cJ64I-0002Ck-BK for bug-gnu-emacs@gnu.org; Mon, 19 Dec 2016 17:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 19 Dec 2016 22:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17742 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17742-submit@debbugs.gnu.org id=B17742.14821851048395 (code B ref 17742); Mon, 19 Dec 2016 22:06:02 +0000 Original-Received: (at 17742) by debbugs.gnu.org; 19 Dec 2016 22:05:04 +0000 Original-Received: from localhost ([127.0.0.1]:48031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJ63L-0002BL-P0 for submit@debbugs.gnu.org; Mon, 19 Dec 2016 17:05:04 -0500 Original-Received: from mail-qk0-f170.google.com ([209.85.220.170]:33811) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJ63J-0002An-Py for 17742@debbugs.gnu.org; Mon, 19 Dec 2016 17:05:02 -0500 Original-Received: by mail-qk0-f170.google.com with SMTP id q68so30337704qki.1 for <17742@debbugs.gnu.org>; Mon, 19 Dec 2016 14:05:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YHL2UMjvdUg3dxUnzHQlD648mwuoWczhje8V0WNxCDk=; b=XmtyFK795RvfGzcUGNA5F90TIzCqoJbZU9BqL5NsKOxHNKxtudSk+b1jw90W9BpuiO JDSOLc3h8zcyS2ocMo+fN47SrEUOa0jK5wrqfGP1wgd+pw1BtANxhcAnlmv29Aa0kJcH OD7wAUWU0nUnV+dSYXF+gKN1AtGJTicbh2uGY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YHL2UMjvdUg3dxUnzHQlD648mwuoWczhje8V0WNxCDk=; b=W4fcFxXRB8yjvzoV0mXGy2uERnNx5058yg9LH2wKE2ZLgrhouU04sCUrn7xWTPtGhp fJ9b0MyOQzzQZnpFhlXI+BwvLOLtiUwGWcw5RzO4cFTaQ4eXN+OmyRAP4fubcWXoAHsJ l/fLbavseGA8KVqqVqMSjDBIOw/wgualpfMgbEf+IvCAmVN64V5T3nVk/FNUye7Dz2b4 E9I1npAqL2zmHnnv+vTDCdHzIzbTN1UaP4facuF8HzhsISpo1vqaPuppgmNuAmzmtkMl CNYuoOnfeqiQ7cYWxJr4QARUw2wZyJJov8KmvZXsuQo9jIxFFHEctM74Dl1P8eMAaG59 VM2g== X-Gm-Message-State: AIkVDXLemfLMulA+cl8U9ITSOBODQv6RDc7Dnr762znK9ufN5K3Ng1G6trNXkzCx7FzsjItksUnryVE/9kHSohts X-Received: by 10.55.115.71 with SMTP id o68mr5204253qkc.270.1482185096350; Mon, 19 Dec 2016 14:04:56 -0800 (PST) Original-Received: by 10.140.88.51 with HTTP; Mon, 19 Dec 2016 14:04:55 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:127222 Archived-At: --001a114f5c2e2910d405440a1c3f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 19 December 2016 at 21:47, Reuben Thomas wrote: > > =E2=80=8BHaving discovered that Aspell does not provide this information = (I > checked again, and ispell-aspell-find-dictionary does not find this > information in the dictionaries, except for limited information about > otherchars; for casechars and not-casechars it defaults to [:alpha:]), I > shall investigate with the hunspell maintainers.=E2=80=8B > =E2=80=8BHunspell has an open bug to export an API to get the casechars (wh= ich hunspell calls "WORDCHARS"): https://github.com/hunspell/hunspell/issues/282 It has been added to the 2.0 milestone. So it seems there is light at the end of this particular tunnel. I've added a comment that it would be good to have a way to get this information from the hunspell binary too. My suggestion on how to proceed would therefore be: 1. Assuming my patches to enchant are accepted sooner rather than later, and there's a minor Enchant release soon, then accept an initial implementation of Enchant support in Emacs with a fixed casechars value. This is no worse than for Aspell. 1a. If someone wants to add a way for Emacs to parse hunspell dictionaries when used via Enchant, that's fine by me as a temporary workaround. 2. When hunspell 2 is released, hopefully there will be an official channel for Emacs to get this information. Any workaround introduced as per 1a above would now be more solid. 3. Once one of Enchant's supported engines has an official way to get this information, then it's a good time to add an API to Enchant too (and support in the standalone binary). Overall, there's no hurry. We have precise casechars for hunspell dictionaries today (though as I mentioned elsewhere, there may still be problems with using them). Enchant support for now is useful for the spelling checkers it supports that Emacs does not; obviously, Emacs's direct hunspell support is better for now than via Enchant. It would be nice to fix that eventually and use only Enchant, but there's no need to rush. --=20 http://rrt.sc3d.org --001a114f5c2e2910d405440a1c3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = 19 December 2016 at 21:47, Reuben Thomas <rrt@sc3d.org> wrote:

=E2=80=8BHaving discovered t= hat Aspell does not provide this information (I checked again, and ispell-a= spell-find-dictionary does not find this information in the dictionaries, e= xcept for limited information about otherchars; for casechars and not-casec= hars it defaults to [:alpha:]), I shall investigate with the hunspell maint= ainers.=E2=80=8B

<= div>
=E2=80=8BHunspel= l has an open bug to export an API to get the casechars (which hunspell cal= ls "WORDCHARS"):

https://githu= b.com/hunspell/hunspell/issues/282

It has been added to the 2.0 milestone. So it seems th= ere is light at the end of this particular tunnel.

I've added a comment that it would be good to= have a way to get this information from the hunspell binary too.

My suggestion on how to proceed wo= uld therefore be:

1. Assu= ming my patches to enchant are accepted sooner rather than later, and there= 's a minor Enchant release soon, then accept an initial implementation = of Enchant support in Emacs with a fixed casechars value. This is no worse = than for Aspell.

1a. If s= omeone wants to add a way for Emacs to parse hunspell dictionaries when use= d via Enchant, that's fine by me as a temporary workaround.

2. When hunspell 2 is released, hope= fully there will be an official channel for Emacs to get this information. = Any workaround introduced as per 1a above would now be more solid.

3. Once one of Enchant's supp= orted engines has an official way to get this information, then it's a = good time to add an API to Enchant too (and support in the standalone binar= y).

<= div class=3D"gmail_default" style=3D"font-size:small">Overall, there's = no hurry. We have precise casechars for hunspell dictionaries today (though= as I mentioned elsewhere, there may still be problems with using them). En= chant support for now is useful for the spelling checkers it supports that = Emacs does not; obviously, Emacs's direct hunspell support is better fo= r now than via Enchant. It would be nice to fix that eventually and use onl= y Enchant, but there's no need to rush.

--
http://rrt.sc3d.org
--001a114f5c2e2910d405440a1c3f--