--- Begin Message ---
|
Subject: |
[PATCH] Improved regexp-opt KEEP-ORDER check |
|
Date: |
Sun, 30 Jun 2019 14:28:57 +0200 |
Currently, regexp-opt does not attempt optimisation with KEEP-ORDER set if the
input list contains a proper prefix of another element, like
("ab" "abcd")
on the grounds that the optimised string would be
"ab\\(?:cd\\)?"
which would not preserve the match order. However, this also prevents
("abcd" "ab")
from being optimised, even though doing so would be harmless.
The attached patch strengthens the check, allowing more inputs to be optimised.
0001-Optimise-more-inputs-to-regexp-opt.patch
Description: Binary data
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#36444: [PATCH] Improved regexp-opt KEEP-ORDER check |
|
Date: |
Thu, 4 Jul 2019 17:18:40 +0200 |
4 juli 2019 kl. 16.18 skrev Noam Postavsky <address@hidden>:
>
>> Not too fond of that either, really; catch/throw somehow seems more
>> heavyweight than warranted by the situation.
>
> I've wondered if it's worth making a lexical variant of catch/throw that
> could be compiled as goto for these kind of situations.
Yes, although in this case I'd settle for built-in some/every constructs
without bootstrap trouble, or list comprehensions that aren't a mysterious
corner of cl-loop.
>> (1) Same as before, but with a comment about what tripped you up:
>
>> (2) Using cl-loop:
>
> Assuming (eval-when-compile (require 'cl-lib)) avoids bootstapping
> problems, I think the cl-loop variant is a bit neater; but either way is
> fine with me.
Thank you; I went with the while-loop, on the grounds that it can be readily
understood by the layman from first principles. I have yet to be entirely
friends with cl-loop.
Pushed to master.
--- End Message ---