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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 22090 <at> debbugs.gnu.org, bruce.connor.am <at> gmail.com
Subject: Re: bug#22090: Isearch is sluggish and eventually refuses
 further	service	with "[Too many words]".
Date: Fri, 04 Dec 2015 22:08:48 +0200

> Date: 4 Dec 2015 19:21:26 -0000
> From: Alan Mackenzie <acm <at> muc.de>
> Cc: 22090 <at> debbugs.gnu.org
> 
> > (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'm not sure the use cases related to case folding should be working
in principle.  That's because normalization under case folding means
first downcase, then decompose; it is not allowed to downcase the
decomposition.  So if this issue is only about those, I don't think
there's anything to sort out here, thanks.

Previous Next

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