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

[Drew Adams]

> FWIW I just introduced Emacs to a newbie last month -- using trunk Emacs
> because that's what I happened to have available. She was very happy
> indeed about not only isearch, not only case-fold search but
> specifically char-fold search, and she writes stuff using diacritics all
> the time.
> 
> The key to remember here is that there are many use cases in which it is
> better if isearch finds something similar to what you typed than if it
> misses something you were looking for: you can always hit C-s again!
> So thanks to case-fold and char-fold search she doesn't have to worry
> about getting either the case or diacritics right, and can cut down on
> chording and compose characters while searching.
> 
> So that's one newbie in particular who would vociferously disagree
> with you.
> 
> > What should be done is to have simple, obvious default behavior,
                                                   ^^^^^^^
> She found "searching ignores accent-like things and case" to be easy
> and instantly understandable, even though the implementation of
> ignoring even case is (thanks to case-conversion tables) quite
> complicated in a Unicode world.

Anecdotal evidence from one newbie.  OK.

I don't see anything in your description of her understanding of
Isearch that shows that she "would vociferously disagree" with
my proposition that literal search is a better default behavior,
but I guess that is how you feel.  So be it.

Nevertheless, I wonder a bit about her nonsurprise and instant
understanding wrt char folding.  Did she just search for
something like `a' and find things like `á'?  Or did she also
search for something like `á' and find things like `a'?  (She
could not have, as that is not yet implemented, AFAIK.)

I would be somewhat surprised if she would not be somewhat
surprised that looking for `á' can find `a'.

Note the current discussion and the Subject line.  This
thread is about making char folding treat `á' and `a' as
equivalent, i.e., both directions.

I think it should be clear that searching for and finding
exactly what you type is _absolutely_ easier to understand
than finding things that you did not type.  Of course, both
literal and dwim searching might be easy enough in some
contexts or for some users.

So sure, this absolute difference in ease of understanding
does not preclude the existence of some users for whom even
the most complex mapping of search string to search hits
might be "easy and instantly understandable".  Such users
should not be bothered by whichever behavior is chosen as
default.

Regexp vs literal search is a good example of literal search
being easier to "get".  Regexp search requires some extra
understanding of, or feeling for, the mapping between search
patterns and what the patterns match; literal search does not:
what you type is what you find, literally.

I doubt that all newbies expect our whitespace folding or
find it natural.  Likewise, how non-nil `case-fold-search'
treats the presence of an uppercase letter in the search
string.

These things are not obvious, in general, even if you can
point to a new user for whom they seem to be obvious.  The
uppercase-letter-in-search-string behavior, in particular,
is unusual - not common in text editors.  That might have
made sense as default behavior for Emacs in 1985, but now?

These things are gotchas, even if there might be some
newbies who do not seem to have ever been "got" by them.
It is better not to make such behavior the default, as
long as the alternative is useful.

And it is easy enough to customize search to make such
dwim searching the default for any particular user.
And it is trivial to toggle the behavior anytime.
There is no special reason to make the default behavior
a "gotcha" one.

The _only argument_ that I have heard, for making folding
searches the default behavior, and the only one that I can
imagine, is that if we do not do so then users might not
discover them quickly, and so they might miss out on how
useful they can be.

I repeat what I said before about that:

  Discoverability is not an argument for choosing any
  default behavior.

  Poor discoverability is an argument for improving
  discoverability.  Nothing more.

> The key to remember here is that there are many use cases in
> which it is better if isearch finds something similar to what
> you typed than if it misses something you were looking for

No, that is not anything key to remember, in this discussion.

No one has doubted that non-literal search can be extremely
useful.  That is in fact one of the reasons for this thread:
make char-fold search do exactly that for any char in the
search string, including for a char with diacritics.
Currently, it always searches only literally for `á', even
when char folding is turned on.

It should be clear that no one is arguing against the
usefulness of folding search.  The post you responded to
was a counter to the false argument that we should turn
char folding on by default because it facilitates discovery
of this nifty feature.

This thread is not really about what the default behavior
should be, but I did address that extraneous argument,
and you did respond.  If there is a need to continue about
that topic, we should do it in a separate thread.