GNU bug report logs - #22090
Isearch is sluggish and eventually refuses further service with "[Too many words]".

Previous Next

Package: emacs;

Reported by: Alan Mackenzie <acm <at> muc.de>

Date: Fri, 4 Dec 2015 04:26:01 UTC

Severity: normal

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: bruce.connor.am <at> gmail.com
Cc: 22090 <at> debbugs.gnu.org, acm <at> muc.de
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 <at> gmail.com>
> Cc: Alan Mackenzie <acm <at> muc.de>, 22090 <at> debbugs.gnu.org
> 
> 2015-12-05 17:32 GMT+00:00 Eli Zaretskii <eliz <at> 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.




This bug report was last modified 9 years and 171 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.