[Top][All Lists]

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

[debbugs-tracker] bug#36444: closed ([PATCH] Improved regexp-opt KEEP-OR

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#36444: closed ([PATCH] Improved regexp-opt KEEP-ORDER check)
Date: Thu, 04 Jul 2019 15:19:01 +0000

Your message dated Thu, 4 Jul 2019 17:18:40 +0200
with message-id <address@hidden>
and subject line Re: bug#36444: [PATCH] Improved regexp-opt KEEP-ORDER check
has caused the debbugs.gnu.org bug report #36444,
regarding [PATCH] Improved regexp-opt KEEP-ORDER check
to be marked as done.

(If you believe you have received this mail in error, please contact

36444: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36444
GNU Bug Tracking System
Contact address@hidden with problems
--- 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


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.

Attachment: 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 ---

reply via email to

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