--- In [email protected], "entropyreduction"
<alancampbelllists+ya...@...> wrote:
>
> --- In [email protected], "Sheri" <sherip99@> wrote:
> >
> > --- In [email protected], "entropyreduction"
> > <alancampbelllists+yahoo@> wrote:
>
> >
> > The bsr_unicode and bsr_anycrlf options are kind of like the
> > various newline_options, they override a library default. The
> > newline options also have a interior pattern alternatives. I
> > think you had to do something special for the plugin/external
> > newline options.
>
> So if library default is e.g. bsr_unicode, I need to turn that
> off in presence of bsr_anycrlf...that makes sense. Will try.
Sounds logical.
>
> There's a bunch of nasty code to do with what happens if match
> fails but one of the multicharacter newline options is in force,
> then I have to step one character and try again.
I don't think anything similar would apply for bsr_unicode or
bsr_anycrlf. It is possibly PCRE fixes made that step-one-character
logic unnecessary for newline options (but lets not go there right now).
>
> const DWORD CPcreAcess::M_NEWLINE_OPTIONS_ALL =
> PCRE_NEWLINE_ANY | PCRE_NEWLINE_CRLF | PCRE_NEWLINE_CR |
> PCRE_NEWLINE_LF | PCRE_NEWLINE_ANYCRLF;
>
The bsr options are mutually exclusive. bsr_anycrlf makes \R match
certain things and bsr_unicode makes it match those things plus
others. Like newline options bsr option can be changed after pattern
is compiled. So might show up in the handle form of plugin's
pcreservices. I should probably add a handle-form test.
Result on pcrecallback including cbx("callback", "yes") looks right
now. I will need to test it more thoroughly.
Regards,
Sheri
