bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]".

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 5 Dec 2015 18:12:52 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: Alan Mackenzie <acm@muc.de>, 22090@debbugs.gnu.org
> 
> 2015-12-05 17:32 GMT+00:00 Eli Zaretskii <eliz@gnu.org>:
> >> Because there are some characters in each regexp that don't have
> >> lower/upper-case equivalents. For instance, if I use the
> >> "\\(\\(a[´`]?\\|[áà𝑎]\\)" regexp, that's enough to match A or À, but
> >> it's not enough to match a variety of other chars (𝔸𝕬𝖠𝗔𝘈𝘼𝙰🄰).
> >
> > You don't need to match the latter set.  Character folding is applied
> > _after_ case folding, not before.  So characters that don't have a
> > lower-case variant simply shouldn't match a lower-case a -- and they
> > won't, if you just let case-insensitive regexp matching do its job.
> 
> Given that char-folding is a new feature, how it combines with
> case-folding is entirely up to us, and I have really no idea what
> would be TRT.

I don't think there's any reasonable alternative, because for
characters that have a decomposition, you wouldn't downcase the result
of the decomposition, would you?

The Unicode Standard also says this much (p.158):

  In principle, normalization needs to be done after case folding,
  because case folding does not preserve the normalized form of
  strings in all instances.

(There are a couple of examples there showing why the reverse order
could cause incorrect results.)

So if this is true for normalization, it should also be true for the
case in point.

> However, if that is your opinion, I'm more than happy to accept that
> the current situation ('a' doesn't match '𝔸𝕬𝖠𝗔𝘈𝘼𝙰🄰') is TRT,
> given that it has the simplest implementation. :-)

Yes, I think it's TRT.