On 13 December 2016 at 18:54, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Reuben Thomas <rrt@sc3d.org>
> > Date: Tue, 13 Dec 2016 18:26:43 +0000
> > Cc: 17742@debbugs.gnu.org
> >
> >  I understand that Enchant doesn't yet support these features, but in
> >  that case we must provide our users with some way of customizing these
> >  settings, we cannot silently use defaults that are most probably
> >  inappropriate, even if they are 90% correct.
> >
> > ​The way to customize it is surely the same as currently, namely​ to
> customize ispell-dictionary-alist?​
>
> That's okay, but then ispell.el shouldn't be generating dictionary
> entries, but instead should leave that to the user, as we do with
> Ispell.
>
> > Given that even management of personal word lists needs a patch to
> Enchant, it seems to me better to first
> > try to engage with the Enchant maintainers on this. There's also one
> obvious question, namely, what do other
> > Enchant users do? Enchant is used in Abiword (free word processor),
> Pidgin (free IM client) etc. So, I shall
> > look into this.
>
> Thanks.
>

​I have not had any response to my enquiries yet, but I did some research,
and neither GNU Aspell nor hunspell offer any way to get this information
(about character classes of dictionaries) via their APIs.

This suggests that they do not see a need for it. Perhaps it is worth
confirming whether Emacs really needs this information?

As far as I can see, it is used only in flyspell-word, for per-word
spell-checking. (The only caller outside flyspell.el is erc, which has a
FIXME saying not to call flyspell-word.) As far as I can see, the code
assumes that words are a convenient unit to check and cache, though there's
no definite requirement for that: in particular, the spelling checkers will
say what words are incorrectly spelled and where they are without having to
be given precisely the word. I guess that other editors and word processors
work this way.

For example, aspell.h contains the following notice about
aspell_document_checker_process:

 * The string passed in should only be split on
 * white space characters.

So a reasonable definition of cache units (I will not say "words" any more)
might be whitespace-delimited strings. This would not need casechars,
not-casechars, otherchars and many-otherchars-p.

I've put this on my to-investigate list for the future; of course, if
there's an obvious reason it wouldn't work, do let me know!

-- 
http://rrt.sc3d.org