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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#52394: 27.2; Isearch with char folding enabled doesn’t match equival


From: Juri Linkov
Subject: bug#52394: 27.2; Isearch with char folding enabled doesn’t match equivalent strings
Date: Fri, 10 Dec 2021 09:51:06 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu)

> Launch `emacs -Q`, paste these four lines on a buffer
>
> aaaaaaaaa'aaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaa'aaaaaaaaaaaaaaaaaaa'aaaaaaaaaa
> aaaaaaaaa’aaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaa’aaaaaaaaaaaaaaaaaaa’aaaaaaaaaa
>
> nnnnnnnnn'nnnnnnnnnnnnnnnnnnnnnnnnnnnn nnnn'nnnnnnnnnnnnnnnnnnn'nnnnnnnnnn
> nnnnnnnnn’nnnnnnnnnnnnnnnnnnnnnnnnnnnn nnnn’nnnnnnnnnnnnnnnnnnn’nnnnnnnnnn
>
> Search for the first one with char folding enabled. In my system Emacs
> doesn’t match the second line. It matches after I hit ‘C-M-d’ to
> delete the last character from the search query.
>
> If you search with char folding enabled for the third line then it
> does match the fourth, even though the third and the fourth lines are
> just copies of the first two with the a’s replaced by n’s.

Please note that when the search string is too long for char folding,
then it displays the message at the end of the Isearch prompt
before disabling char folding:

  "Too many words; switched to literal mode"

Char folding is regexp-based and converts the search string
into a very long regexp that matches all character variants.
But the regexp have limitations when matching runs out of
internal stack space.  This is described in the Info node:

  (info "(elisp) Regexp Problems")

For example, my stack is longer than yours, so the second line
of the described case matches with line length of 74 characters.
But the search still switches to literal mode on 87 characters.





reply via email to

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