GNU bug report logs - #21164
25.0.50; char-fold search broken for multi-line searches (sometimes)

Previous Next

Full log

View this message in rfc822 format

From: Artur Malabarba <bruce.connor.am <at> gmail.com>
To: Juri Linkov <juri <at> linkov.net>, emacs-devel <emacs-devel <at> gnu.org>
Cc: Dima Kogan <dima <at> secretsauce.net>, 21164 <at> debbugs.gnu.org
Subject: bug#21164: 25.0.50; char-fold search broken for multi-line searches (sometimes)
Date: Wed, 5 Aug 2015 19:16:22 +0100

There is some logic in `isearch-search-fun-default' that I don't quite
understand, and it's giving me trouble.
The following expression is used to decide whether lax-whitespace
matching should be used.

;; Use lax versions to not fail at the end of the word while
;; the user adds and removes characters in the search string
;; (or when using nonincremental word isearch)
(let ((lax (not (or isearch-nonincremental
                    (null (car isearch-cmds))
                    (eq (length isearch-string)
                        (length (isearch--state-string
                                 (car isearch-cmds))))))))
  ...)

I don't understand the purpose of the last clause `(eq (...) (...))'.
For me, the only effect that it has is to disable lax while isearch is
looking for matches beyond the current one.

For instance, here's what happens with me:

1. Type C-s SPC to start isearching for a space.
2. All of the clauses evaluate to nil, and the `isearch-word' function
is called with LAX being t (all good).
3. Immediately (without me typing anything), isearch will start
looking for the next match, but this time the last clause will
evaluate to t. So the `isearch-word' function will be called with LAX
being nil, and some of the upcoming matches will be missed.
4. Step 3 is repeated to find more matches, always with lax being nil.

Previous Next

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