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

[Drew Adams]

>   > Nothing more.  What's good for `e' should be good for `é' and
>   > all the rest.  It's about equivalence classes.
> 
> That would be a change for the worse, since it would reduce the range
> of searches that the user can specify with one character in the
> search.

Not at all.  It adds to what the user can do.  It does not subtract.

> Currently the user can either search for "any kind of e" or "only é"
> or "only è" or "only ê", etc.

That would still be the case.

The only difference would be that when s?he wants to search for "any
kind of e" s?he can use any of the equivalent e-chars.  Any of [eéèêæë]
would behave the same as `e' does not, when searching for any of [eéèêæë].

> With your change, the user would be limited to searching for "any kind
> of e".  That would be a step back in flexibility.

Not at all.  Just as now, the user can toggle char folding OFF, to
search for the search string literally, i.e., to take its chars as
what they are, and not consider them as representative of an
equivalence class.

With folding OFF, `e' searches only for `e'; `é' searches only for `é',
and so on.

These are all of the possible possibilities, for `e' and `é':

Folding ON/OFF  Search string char   Buffer chars that match
--------------  ------------------   -----------------------

OFF             e                    [e]
OFF             é                    [é]
ON              e                    [eéèêæë]
ON              é                    [eéèêæë] <======= MISSING NOW

And the same goes for any of the other e-chars.  With folding off
it matches only itself.  With folding on it matches any of its class.

This proposal adds more matching possibilities.  It does
not remove any possibilities.

Currently, you cannot do what is shown in the last line above.
You cannot use é to search for [eéèêæë].  Similarly, you cannot
use a curly quote to search for other kinds of quote marks.

You are currently limited to using only the "canonical" chars
that represent their class.  That removes the possibility of
pasting text into the search string and being able to get
char-folding search.

Quote marks are a good example chars in text that you might copy
and try to search for.  To do that, if the copied text contained
curly quotes then you would need to use `M-e' and edit the search
string, to convert each of them to the corresponding "canonical"
member of the quotation-mark equivalences, an ascii quote mark.

There is no good reason to make users jump through such a hoop.
(Plus, they would need to know what the "canonical" char is, for
each equivalence class they might want to use.)  Let any member
of a class represent the class.

> Since the current interface is fairly natural, there is no loss in
> offering the user all these options.

All what options?  The proposal does not remove any matching options.
On the contrary, it adds matching options.

> I would not oppose offering a configuration setting to get the
> behavior you want.  There is nothing to lose with that.  But the
> current behavior is a more useful default than the behavior you would
> like.

Did you understand what is being proposed, when you wrote that?

If so, how is the current restriction to `e' for matching [eéèêæë]
more useful than letting any e-char do the same?