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

[Davis Herring <herring@lanl.gov>]

>> Because having both input characters mean the same thing
>> uselessly deprives the user of expressive power.
> 
> Examples/arguments/reasons, please.  IOW, prove it.

I'm sorry: I thought it was obvious.  For case folding, there are three
sets of characters that might be considered a match: [a], [A], and [aA].
 The default Emacs behavior is to make "a" mean [aA] and "A" mean [A].
For the (relatively rare) case in which [a] is desired, one can turn
case-fold-search off (e.g., with M-c).  Then you gain [a] and lose [aA]
as a choice (you can't have all three from just two characters!).

With your suggestion (which addresses only case-fold-search, of course),
we would have only [aA] available whether you typed "a" or "A".  That is
the less expressive power: the semantically distinct options available
have been reduced.

Of course, with more than one character there are yet other
possibilities: for two characters there are 9, of which "ab" gives you
[aA][bB] and each of the other three permutations give one
(case-sensitive) match each.  4/9 isn't great, but it's better than 1/9!

> IMO, more users have been tripped up than helped by the rule
> that "An upper-case letter anywhere in the incremental search
> string makes the search case-sensitive." (emacs) Search Case.

How did that upper-case letter get there?  Commands like C-w are careful
not to add uppercase letters if there aren't already some.  So the user
must have typed it explicitly, and so they were paying attention to case
and have no need for a case-insensitive search.  The only harm is if
they are inconsistent in their typing -- during something as brief as
isearch.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.