Subject: bug#36444: closed (Re: bug#36444: [PATCH] Improved regexp-opt KEEP-ORDER check)

From: [email-masked] (GNU bug Tracking System)
Date: Thu, 04 Jul 2019 15:19:02 +0000

Your bug report

#36444: [PATCH] Improved regexp-opt KEEP-ORDER check

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
36444: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36444
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#36444: [PATCH] Improved regexp-opt KEEP-ORDER check
From: Mattias Engdegård <[email-masked]>
To: Noam Postavsky <[email-masked]>
Cc: [email-masked]
Date: Thu, 4 Jul 2019 17:18:40 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

4 juli 2019 kl. 16.18 skrev Noam Postavsky <[email-masked]>:
> 
>> 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.

Subject: [PATCH] Improved regexp-opt KEEP-ORDER check
From: Mattias Engdegård <[email-masked]>
To: [email-masked]
Date: Sun, 30 Jun 2019 14:28:57 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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.