--- In power-pro@yahoogroups.com, "Sheri" <sheri...@...> wrote:
> > > > > Possibly a new plugin option should trigger the EXTRA block, flag, etc., > > > similar to the trigger that was added to pcretest to avoid unnecessary > > > overhead. And you suggested a new plugin variable regex_mark for storing > > > any returned string. > > > > EXTRA block only needed if MARK present in pattern? > > > > If so, how about I just check pattern for "MARK", and if present turn on > > EXTRA stuff? > I think there are numerous variations, not just the presence of "MARK", and > possibly more will get added in future versions. Okay, "extra" is option. Compile time option, yeah? Short version? x, X taken, e seems free. > > > There was also a new PCRE_UCP compile time option added in 8.10. Even > > > without adding it to the plugin, we can already use it via an internal > > > pattern option. > > So skip that? > > No, no reason it should be skipped. We have plugin options for all the other > ones despite there are internal pattern options available for some of them. Okay "ucp"? Short version? > I did agree with that assessment when I read it. But this only returns the > last mark string it encounters, not each of multiple. > > > > Thoughts? > > > > > > Never mind. Assuming only one markstring can happen as a result of > > > > call to plugin pcreMatch, could plonk it in a new standard variable, > > > > e.g. regex_mark. > > > > > > I assume markstrings would be ignored in pcreMatchall, pcrerReplace > > > > I don't understand what purpose of MARK would be in pcreMatchall or > > pcrerReplace. Do yo? > > > > Suppose the pcrematchall or pcreReplace function was used to process only one > match? In addition to processing the replacement, additional info about the > match could be retrieved. Saves needing to test with pcreMatch separately in > that case. Maybe. Yep, okay. As you say, rpboably easier to just let it rip for any of the services. No immediate action on these, though I'll start reading the 8.10 API docs.
