bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Fri, 04 Dec 2015 22:08:48 +0200

> Date: 4 Dec 2015 19:21:26 -0000
> From: Alan Mackenzie <acm@muc.de>
> Cc: 22090@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]