Re: Embedded modifiers in the regex engine

[Dima Kogan]

On February 25, 2016 8:15:52 AM PST, Eli Zaretskii <address@hidden> wrote:
>> From: Dima Kogan <address@hidden>
>> Date: Wed, 24 Feb 2016 17:32:01 -0800
>> 
>> I've been thinking of ways to make some fancier aspects of isearch
>and
>> hi-lock work better, specifically, the way we handle the different
>> modes: case-fold, char-fold, lax-whitespace, etc.
>> <snip>
>> 
>> The best solution I can think of to clean this up is also the most
>> intrusive: adding support for pcre-style embedded modifiers to
>> activate/deactivate the modes.
>> 
>> So for instance "\\(?i\\)asdf" would be interpreted as a case-folding
>> regex regardless of the value of case-fold-search.
>
>I hope you are not proposing this as a replacement for the M-s
>toggles, because if so, I'm very much opposed.

This proposal is concerned with the internals of the regex parser only, so not 
trying to break M-s toggles.


>> As an example, currently hi-lock generates a complicated-looking
>regex
>> to emulate char-folding and case-folding. If we supported the
>modifiers,
>> this change would simply be a prepend of "\\(?i\\)" or whatever other
>> modes we want. This is simple and expected to be bug-free on the
>hi-lock
>> level. Bugs such as hi-lock not supporting char-fold and case-fold at
>> the same time would not happen.
>
>They will also not happen once character-folding is implemented via
>translation tables, instead of regular expressions.  The current
>implementation will go away at some point (one hopes).

OK, that's good to hear, but char-fold isn't causing all the funkyness here.

I'm looking at importing the regex test suite in glibc to emacs. Would this be 
possible even if the copyright holders of those tests haven't assigned their 
work to the fsf? These are tests and not part of emacs on some level, so would 
that make it ok?