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

Previous Next

Full log

Message #49 received at 22090 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: bruce.connor.am <at> gmail.com
Cc: 22090 <at> debbugs.gnu.org
Subject: Re: bug#22090: Isearch is sluggish and eventually refuses further
 service	with "[Too many words]".
Date: 4 Dec 2015 19:21:26 -0000

Hello, Artur.

In article <mailman.1363.1449242229.31583.bug-gnu-emacs <at> gnu.org> you wrote:
> 2015-12-04 9:23 GMT+00:00 Eli Zaretskii <eliz <at> gnu.org>:
>>> Date: Fri, 4 Dec 2015 04:20:52 +0000
>>> From: Alan Mackenzie <acm <at> muc.de>
>>>
>>> With a recent emacs-25 (last update
>>> eaa1fd6dbff8346eb38485de5ebf0fbfacf374d9 from Thursday 2015-12-03):
>>>
>>> emacs -Q
>>> C-c C-f src/xdisp.c
>>> Move point to L30 (paragraph beginning "Updating the display is triggered
>>>   by the Lisp interpreter ...")
>>>
>>> C-s
>>> C-w repeatedly, to yank words onto the search string.
>>>
>>> After ~29 words have been yanked, the response becomes sluggish, pausing
>>> for between 0.5s and 1s before highlighting the "for" at the end of L31.

> Thanks for the report. The source for this (and for a similar bug
> mentioned on a thread in emacs-devel) was the code I had added for
> special case-folding support.
> For now, I've just removed the code. I can think of a way of solving
> this, but it adds some complexity to isearch, which I don't wanna do
> (and I don't think this feature was that important anyway). Here's a
> full copy of the commit message explaining why the bug happens.

> 30f3432 * lisp/character-fold.el: Remove special case-folding support

> (character-fold-to-regexp): Remove special code for
> case-folding.  Char-fold search still respects the
> `case-fold-search' variable (i.e., f matches F).  This only
> removes the code that was added to ensure that f also matched
> all chars that F matched.  For instance, after this commit, f
> no longer matches 𝔽.

> This was necessary because the logic created a regexp with
> 2^(length of the string) redundant paths.  So, when a very
> long string "almost" matched, Emacs took a very long time to
> figure out that it didn't.  This became particularly relevant
> because isearch's lazy-highlight does a search bounded by (1-
> match-end) (which, in most circumstances, is a search that
> almost matches).  A recipe for this can be found in bug#22090.

Would you like any help to sort out these regexps?  I have some expertise
in doing this, having half-written fix-re.el, a program which analyses
and corrects just the sort of thing you're talking about.

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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