RE: char equivalence classes in search - why not symmetric?

[Drew Adams <drew.adams@oracle.com>]

>   > They are equivalence classes.  The chars are equivalent when searched
>   > for (with char folding turned on).
> 
> No, they aren't.  For instance, A and Á are not equivalent in search.
> Searching for A will match Á, but searching for Á will not match A.

Please read what I said: "The chars are equivalent when searched for."
                                                   ^^^^^^^^^^^^^^^^^

I did *not* say, as you say, that they are "equivalent in search."
I tried to carefully distinguish the two uses of the chars: when used
as search targets (they are currently equivalent) vs when used in the
search string (they are not equivalent, currently).

If you search for A with char folding on you will find both A and Á
(and all the rest of the A family).  All members of that family (class)
are equivalent _as search targets_.  Currently.  100% equivalent.
They form an equivalence class wrt the operation of searching _for_
them.

They are not yet equivalent also as search patterns, i.e., when used
in the search string.  That is the proposal of this thread: to make
them equivalent also in their use in a search string (when char
folding is turned on).
 
> To make them equivalent would be a change for the worse.
> I already explained why.

The only explanation I saw from you was that you want the presence
of an accented char in the search string to automatically turn off
char folding.  That's your preference.

It leads to an absolute reduction of possibilities for users (they
cannot use abstract from accented search when there are accented
chars in the search string).  But you have every right to prefer
that limitation.

Please be aware that with what is being proposed a user can still,
anytime, get diacritic-sensitive search when there are accented
chars in the search string (and when there not).  It is sufficient
to toggle off char folding.

You want that toggling off to happen automatically, based on the
mere presence of an accented char in the search string.  I don't,
because users lose the possibility of getting char-folded search
whenever there are accented chars in the search string.  They
then need to edit the search string if they want to abstract from
diacritics, replacing any such chars with the unaccented ("base")
versions, in order to get char-fold search.

In the code I sent, I provided a user option, to let _users_
decide which behavior they want, individually: the one you
prefer or the one I prefer.  Why not give them the choice?