[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22090: Isearch is sluggish and eventually refuses further service wi
From: |
Eli Zaretskii |
Subject: |
bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]". |
Date: |
Sat, 05 Dec 2015 20:34:33 +0200 |
> 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.
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., (continued)
- Message not available
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Alan Mackenzie, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Eli Zaretskii, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Artur Malabarba, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Alan Mackenzie, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Artur Malabarba, 2015/12/05
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Eli Zaretskii, 2015/12/05
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Artur Malabarba, 2015/12/05
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]".,
Eli Zaretskii <=
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Alan Mackenzie, 2015/12/05
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Artur Malabarba, 2015/12/06