From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]". Date: Sat, 05 Dec 2015 20:34:33 +0200 Message-ID: <831tb0g2x2.fsf@gnu.org> References: <20151204192126.73199.qmail@mail.muc.de> <20151204230000.GC6070@acm.fritz.box> <8337vgg5su.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-Trace: ger.gmane.org 1449340521 27666 80.91.229.3 (5 Dec 2015 18:35:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 5 Dec 2015 18:35:21 +0000 (UTC) Cc: 22090@debbugs.gnu.org, acm@muc.de To: bruce.connor.am@gmail.com Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 05 19:35:10 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a5Hfp-0005e6-W9 for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Dec 2015 19:35:10 +0100 Original-Received: from localhost ([::1]:47402 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5Hfp-0002DQ-8P for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Dec 2015 13:35:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50193) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5Hfm-0002Cq-FC for bug-gnu-emacs@gnu.org; Sat, 05 Dec 2015 13:35:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a5Hfj-0007qT-9g for bug-gnu-emacs@gnu.org; Sat, 05 Dec 2015 13:35:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a5Hfj-0007qO-5z for bug-gnu-emacs@gnu.org; Sat, 05 Dec 2015 13:35:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a5Hfi-0001w5-RQ for bug-gnu-emacs@gnu.org; Sat, 05 Dec 2015 13:35:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Dec 2015 18:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22090 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22090-submit@debbugs.gnu.org id=B22090.14493404877416 (code B ref 22090); Sat, 05 Dec 2015 18:35:02 +0000 Original-Received: (at 22090) by debbugs.gnu.org; 5 Dec 2015 18:34:47 +0000 Original-Received: from localhost ([127.0.0.1]:40072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a5HfT-0001vX-34 for submit@debbugs.gnu.org; Sat, 05 Dec 2015 13:34:47 -0500 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:58246) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a5HfQ-0001vO-5H for 22090@debbugs.gnu.org; Sat, 05 Dec 2015 13:34:45 -0500 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NYW00B00E7O7R00@mtaout29.012.net.il> for 22090@debbugs.gnu.org; Sat, 05 Dec 2015 20:34:37 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYW009M2E9OCN20@mtaout29.012.net.il>; Sat, 05 Dec 2015 20:34:37 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:109662 Archived-At: > Date: Sat, 5 Dec 2015 18:12:52 +0000 > From: Artur Malabarba > Cc: Alan Mackenzie , 22090@debbugs.gnu.org > > 2015-12-05 17:32 GMT+00:00 Eli Zaretskii : > >> 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.