From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#17742: Acknowledgement (Support for enchant?) Date: Wed, 21 Dec 2016 19:13:36 +0200 Message-ID: <83bmw52ojj.fsf@gnu.org> References: <834m2hjbmr.fsf@gnu.org> <83bmwfbxaf.fsf@gnu.org> <837f73bqwv.fsf@gnu.org> <838trb6h7s.fsf@gnu.org> <834m1y4nj7.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1482340529 1787 195.159.176.226 (21 Dec 2016 17:15:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 21 Dec 2016 17:15:29 +0000 (UTC) Cc: 17742@debbugs.gnu.org To: Reuben Thomas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Dec 21 18:15:21 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 1cJkTy-0007UB-4a for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Dec 2016 18:15:14 +0100 Original-Received: from localhost ([::1]:58153 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJkU2-0000bh-Ns for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Dec 2016 12:15:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJkTs-0000Wv-PD for bug-gnu-emacs@gnu.org; Wed, 21 Dec 2016 12:15:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cJkTm-0002ha-Hn for bug-gnu-emacs@gnu.org; Wed, 21 Dec 2016 12:15:08 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35043) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cJkTm-0002hO-Em for bug-gnu-emacs@gnu.org; Wed, 21 Dec 2016 12:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cJkTm-0001E6-7a for bug-gnu-emacs@gnu.org; Wed, 21 Dec 2016 12:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Dec 2016 17:15: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.14823404674656 (code B ref 17742); Wed, 21 Dec 2016 17:15:02 +0000 Original-Received: (at 17742) by debbugs.gnu.org; 21 Dec 2016 17:14:27 +0000 Original-Received: from localhost ([127.0.0.1]:50441 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJkTD-0001D2-2H for submit@debbugs.gnu.org; Wed, 21 Dec 2016 12:14:27 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:42346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cJkTB-0001Co-SH for 17742@debbugs.gnu.org; Wed, 21 Dec 2016 12:14:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cJkT3-00029S-Hw for 17742@debbugs.gnu.org; Wed, 21 Dec 2016 12:14:20 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51740) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cJkT3-00029I-Ee; Wed, 21 Dec 2016 12:14:17 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4166 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cJkT2-0004YV-7o; Wed, 21 Dec 2016 12:14:17 -0500 In-reply-to: (message from Reuben Thomas on Tue, 20 Dec 2016 21:43:32 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:127293 Archived-At: > From: Reuben Thomas > Date: Tue, 20 Dec 2016 21:43:32 +0000 > Cc: 17742@debbugs.gnu.org > > So with casechars set to [:graph:], there's no false positive or false negative. The same argument could be used to claim that casechars can be removed altogether, and we should just send everything to the speller. What I'm saying is that using the correct character set there will ensure that the user gets back useful suggestions, something that is less probable without that. > I don't see why it would be fragile with Enchant when it isn't with > its back-ends. > > ​Because there's no guarantee that Enchant will continue to use backends in the same way as at present.​ When it doesn't, we will revisit this issue and revise the code if needed. That is a hypothetical problem, so we don't need to solve it yet. > > Moreover, even when we send entire lines to the speller, we want to > > skip lines that include only non-word characters. > > > > ​Why?​ > > To avoid false positives and false negatives, as explained above. > > ​But such characters will be ignored by the spellchecker (unless perhaps they occur in the personal word list). So I'm not sure how they would generate false positives or negatives.​ You _assume_ they will be ignored. You don't know that. Using the correct character set frees us from the need of making any such assumtions. > The fact that an API to get the wordchars from hunspell is only now being considered for addition suggests to me that neither the maintainers of hunspell nor the developers of hunspell-using programs have thought this was particularly important.​ I don't see any significance of that fact for us. We understood the importance of that data, and we use it to benefit our users. > I tried to explain that above: you will get falses and/or irrelevant > or missing corrections from the speller. For example, if you send > "foo.bar", and the speller doesn't support '.' as a word-constituent > character, you will get separate suggestions for "foo" and "bar", and > won't get "foobar". > > What happens at the moment (with my Enchant patch) is I get the error "Ispell and its process have different character maps". I wouldn't expect "foobar" in any case, if "." is not a constituent character, though I might be surprised to get a correction for a word I thought I wasn't pointing at (but I could be surprised in this way in any case, if the dictionary has a surprising set of wordchars). Try the same example with foo'bar (including the apostrophe), and see what I mean. Once again, using the correct casechars makes the spell-checking commands more useful than not using them. A mismatch between what the user considers casechars and the corresponding notion of the speller/dictionary will make the results less useful. Sure, it won't be a total failure, but why give up quality if we can have it for a small price of parsing a simple text file? One of the strong points of Aspell and Hunspell over Ispell is that the former are much smarter in producing possible corrections. This is what distinguishes an excellent speller from a merely good one. We should strive to support that quality as best we can, IMO. > I also don't understand why you want to remove this information, that > is already there, is not harder to get with Enchant than it is without > it, and the code which supports it is already there? > > ​I'm not proposing to remove this information. I am proposing not to add it for Enchant yet (because that will require extra work and code), and I am hoping to end up with a simpler way to get it, via the API. I'm uneasy about that, as I already wrote. If we add support for Enchant now without also providing those character sets when we can, then users of Hunspell will suddenly experience some degradation, even if minor one, if they switch to using Hunspell via Enchant. Soon enough we will get bug reports about that. So I'd rather we avoid that. Maybe we should simply wait until Enchant acquires those APIs. Thanks.