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

[Nix]

On 7 Sep 2015, Drew Adams spake thusly:

>> 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 think that counters your anecdotal evidence that newbies would find it
confusing: at least one doesn't. (It's not like either of us are
remotely newbies. Heck, I can't even remember what it was like to be
one, so anecdata is all I have to contribute on this front.)

> 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.)

She did the former, of course -- the latter is harder to type, so I
cannot imagine any situation in which anyone would expect it. The whole
nature of *-fold-search is that you can search for the non-chorded basis
of things that must be typed with chords or which are otherwise
composite and get the composite variants too.

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

Perhaps you never thought of it in terms of the keyboard. :)

> 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 that would be deeply bizarre. Searching for 'Foo' does not find
'foo' when case-fold-saerch is on: this is, as has been noted, precisely
analogous to this longstanding Emacs behaviour.

> 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.

Finding things without having to type the whole thing in is exactly what
isearch has always been about. This is just an extension of that, and
not even a very big one.

> 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.

Are you actually reduced to saying that actual newbies' experience is
obviously less significant than your guesses as to what newbies will
surely find less confusing??

Try it on actual newbies. I bet you they won't be confused, based on my
single data point :)

> I doubt that all newbies expect our whitespace folding or
> find it natural.

Haven't you seen non-geeks typing? They leave multiple spaces routinely
(often due to hitting space at the end of a run of typing, then again at
the start of the next one) and expect them to act like just one. This
seems quite reasonable to me, even if random irregular spacing does look
too ugly for me to perpetrate it myself.

>                  Likewise, how non-nil `case-fold-search'
> treats the presence of an uppercase letter in the search
> string.

The thing is, both of these are more or less obscure. When people
discover that lowercase also finds uppercase, or that non-diacritic also
finds diacritic, they generally respond by not bothering to use
uppercase in search terms for a long time. So by the time they encounter
even the first half of the behaviour you call so confusing they are no
longer quite newbies.

> These things are not obvious, in general, even if you can
> point to a new user for whom they seem to be obvious.

I don't think they're even relevant to new users, precisely *because*
they are not terribly discoverable.

> These things are gotchas, even if there might be some
> newbies who do not seem to have ever been "got" by them.

This would be more convincing if you could point to any instances of
newbies actually being confused by it.

> It is better not to make such behavior the default, as
> long as the alternative is useful.

That ship sailed decades ago.

-- 
NULL && (void)