RE: On language-dependent defaults for character-folding

[Drew Adams]

> The implementation should really be on the C level, like the
> case-folding support.  The current implementation isn't, and
> therefore has several disadvantages some of which were already
> pointed out (e.g., the regexp it uses that gets exposed in some
> situations and causes users to be surprised).

I would like to see a list of the disadvantages laid out clearly.

In general, I prefer that things be implemented in Lisp.
That leaves them far more open to Emacs users, and hence to
imagination and enhancement - which can often help Emacs
farther down the road.

Implementation in C makes great sense in some cases, but it
would help to see the detailed arguments (cases).

The argument that a complex, not-user-friendly, under-the-covers
regexp might sometimes get exposed to users is OK, but it is not
really compelling (for me).  Some users, in some case, might well
want to make use of such a regexp (e.g. tweaking it).  And we
might be able to find ways to not expose it for most uses.

(I don't reject the messy-regexp argument.  I just don't find it
sufficiently compelling on its own.)

> For these and other reasons, 

Can we see them, please?

> I also think we will be unable to move to the higher levels
> mentioned above without first moving the implementation into 
> search_buffer.

How so?  (Reasons.)

If there are important, e.g., performance reasons for coding
some functionality in C, can we at least try to limit it - do
that in component pieces rather than as a monolithic
take-it-or-leave-it whole?

I'm interested in maximizing what Lisp users can do with this,
other things being equal (IOW, use C only for what is absolutely
necessary).