Rafael Garcia-Suarez wrote:
> On 23 December 2010 00:23, karl williamson <public@khwilliamson.com> wrote:
>> No one objected when I said I would implement the /a regex modifier without
>> it affecting caseless matching, so that's what I'm doing. I also said that
>> I would implement an extension which is to prevent an ASCII character from
>> matching any non-ASCII character. Thus for example "\N{KELVIN SIGN}" would
>> not match /[kK]/ under this scenario.
>>
>> We need a way to specify this behavior. I'm leaning to the regex modifier
>> /A, which is /a plus some.
>>
>> Another would be to have doubled modifiers /aa. That is harder to parse.
>
> That is also harder to render in qr// string-i-fication.
>
I had been leaning towards /aa instead of /A because of the paradigm in
regexes that a \N means the opposite of \n, for example, and this means
"more of /a", which 'double a' conveys, at least in American English.
But now I don't know.
As part of the /a patch, there is a new API for translating the encode
for the modifier into its character. That API could just as easily
return a string instead. Also, re::regexp_pattern() returns the
stringification.
Do these solve your concerns? If not, suggestions are welcome
Thread Previous
|
Thread Next