Re: Character folding in the pretest

["Óscar Fuentes" <ofv@wanadoo.es>]

Clément Pit--Claudel <clement.pit@gmail.com> writes:

> My name is a good example in French. Clément and Clement are not
> pronounced the same at all. I gave other examples in other messages.

Sure, there are plenty of similar cases in Spanish. Every Spaniard knows
that "canto" and "cantó" are different words and, most likely, will be
not too upset or even happy while seeing isearch locating "cantó" when
searching for "canto". But the same doesn't apply to n/ñ. If a Spaniard
inputs "sana" on a search box and "saña" is found, he will regard the
software as either buggy, dumb or completely oblivious to Spanish
culture.

I'm unable to make isearch-query-replace work (it gives me
"isearch-query-replace: Wrong type argument: stringp, nil") but if the
replaced elements are the same that gets found with Isearch, the n/ñ
thing can produce lots of hilarious (or embarrassing) anecdotes :-)

> I was not trying to change your POV; mostly to understand it. I think
> you've described a use case that is not covered by the current
> implementation (you want character folding to be smart, and to
> recognize whether the user knows that ñ and n are more different than
> á and a before folding deciding whether to fold ñ into n). But why
> should your use case not being covered by the current implementation
> prevent that implementation from becoming the default?

We are talking about isearch here, the most basic and accessible way of
text searching on Emacs. Introducing a change on how it works with the
consequence of creating an "it is not a bug, it is a feature" experience
for a fair chunk of the world's population seems like something that
should give us pause.

Personally, I'm fine with disabling the feature on my setup, but I'll
advise against setting defaults that appeals to users who see foreign
characters as glyphs instead of thinking on the users who actually see
meaning on those characters.