From: Alan Mackenzie <acm@muc.de>
To: Artur Malabarba <bruce.connor.am@gmail.com>
Cc: 22090@debbugs.gnu.org
Subject: bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]".
Date: Sat, 5 Dec 2015 18:52:20 +0000 [thread overview]
Message-ID: <20151205185220.GF2698@acm.fritz.box> (raw)
In-Reply-To: <CAAdUY-Jj8_pK78x2hyXWLwiOADkmad97Q6LJxtqnirMKCrSfOg@mail.gmail.com>
Hello, Artur.
On Sat, Dec 05, 2015 at 05:23:53PM +0000, Artur Malabarba wrote:
> nn2015-12-04 23:00 GMT+00:00 Alan Mackenzie <acm@muc.de>:
> >> When case-fold-search is on the previous code would simply join these
> >> regexps with "\\(\\(a[´`]?\\|[áà𝑎]\\)\\|\\(A[`´]?\\|[ÁÀ]\\)\\)".
> > Quick question: _why_ do you need to join them? Given that
> > case-fold-search is enabled, couldn't you just use, say, the lower case
> > version?
> Because there are some characters in each regexp that don't have
> lower/upper-case equivalents. For instance, if I use the
> "\\(\\(a[´`]?\\|[áà𝑎]\\)" regexp, that's enough to match A or À, but
> it's not enough to match a variety of other chars (𝔸𝕬𝖠𝗔𝘈𝘼𝙰🄰).
OK, thanks.
> > it looks to me that this redundancy would
> > be quite easy to eliminate - you just need three regexp fragments for
> > the letter "a" - a lower case one, an upper case one and a
> > case-fold-search one.
> Yes, we could go that route. It's just going to add complexity to the
> code that generates the char-fold-table (which is already quite dense)
> and I wonder if it's worth such a corner-case. Like I said, 'a'
> already matches A and À, how much do we want to support this extra
> case-folding?
But it seems the complexity (and it can't honestly be that much,
surely?) is intrinsic to the task being carried out. Sticking a "\\|"
between the upper case and lower case versions clearly doesn't work.
Seriously, how difficult can it be to generate
"\\([Aa][´`]?\\|[áà𝑎ÁÀ]\\)"
, which is a blameless regexp, given where you've already got to?
> > The other thing is that for that single character "a" a 39 character
> > regexp fragment is being generated. Might this have something to do
> > with the "[Too many words]" error I got last night (which comes from the
> > regexp engine returning a "too long regexp" error)?
> yes
I was afraid of that.
> > Even if you can reduce that to, say 19 characters, that's only winning a
> > factor of 2 in the slide towards a too long regexp. It might well be
> > that for a very long regexp, you might have to divide it into shorter
> > sections (a typical long RE will by a sequence of sub expressions,
> > rather than lots of alternatives inside \(...\|........\)).
> I don't understand what you mean. Could you elaborate?
Once you've generated the long regexp, if it's too long, you can split
it up into, say, 3 pieces A, B, C, such that (equal re (concat A B C)).
Then you can do something like:
(and (search-forward-regexp A bound noerror)
(search-forward-regexp (concat "\\=" B) bound noerror)
(search-forward-regexp (concat "\\=" C) bound noerror))
. Though, thinking about it, it might be less painful to enhance the
regexp engine to take longer regexps.
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2015-12-05 18:52 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 4:20 bug#22090: Isearch is sluggish and eventually refuses further service with "[Too many words]" Alan Mackenzie
2015-12-04 9:23 ` Eli Zaretskii
2015-12-04 15:16 ` Artur Malabarba
2015-12-04 15:23 ` Eli Zaretskii
2015-12-04 16:06 ` Artur Malabarba
2015-12-04 16:27 ` Eli Zaretskii
2015-12-04 16:37 ` Artur Malabarba
2015-12-04 18:48 ` Eli Zaretskii
2015-12-04 19:59 ` Artur Malabarba
2015-12-05 9:19 ` Eli Zaretskii
2015-12-04 15:49 ` Random832
2015-12-04 16:21 ` Artur Malabarba
2015-12-04 16:37 ` Random832
2015-12-04 16:51 ` Artur Malabarba
2015-12-04 18:24 ` Eli Zaretskii
[not found] ` <mailman.1363.1449242229.31583.bug-gnu-emacs@gnu.org>
2015-12-04 17:01 ` Alan Mackenzie
2015-12-04 19:21 ` Alan Mackenzie
2015-12-04 20:08 ` Eli Zaretskii
2015-12-04 20:49 ` Artur Malabarba
2015-12-04 23:00 ` Alan Mackenzie
2015-12-05 17:23 ` Artur Malabarba
2015-12-05 17:32 ` Eli Zaretskii
2015-12-05 18:12 ` Artur Malabarba
2015-12-05 18:34 ` Eli Zaretskii
2015-12-05 18:52 ` Alan Mackenzie [this message]
2015-12-06 12:50 ` Artur Malabarba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151205185220.GF2698@acm.fritz.box \
--to=acm@muc.de \
--cc=22090@debbugs.gnu.org \
--cc=bruce.connor.am@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.