[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22090: Isearch is sluggish and eventually refuses further service wi
From: |
Artur Malabarba |
Subject: |
bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]". |
Date: |
Fri, 4 Dec 2015 15:16:23 +0000 |
2015-12-04 9:23 GMT+00:00 Eli Zaretskii <eliz@gnu.org>:
>> Date: Fri, 4 Dec 2015 04:20:52 +0000
>> From: Alan Mackenzie <acm@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.
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Alan Mackenzie, 2015/12/03
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Eli Zaretskii, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]".,
Artur Malabarba <=
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Eli Zaretskii, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Artur Malabarba, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Eli Zaretskii, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Artur Malabarba, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Eli Zaretskii, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Artur Malabarba, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Eli Zaretskii, 2015/12/05
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Random832, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Artur Malabarba, 2015/12/04
- bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]"., Random832, 2015/12/04