bug#17742: Acknowledgement (Support for enchant?)

[Eli Zaretskii <eliz@gnu.org>]

> From: Reuben Thomas <rrt@sc3d.org>
> 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.