--- In [email protected], "Sheri" <sheri...@...> wrote: > > Not urgent, for whenever you might feel like looking at this, Alan: > In the last related message you asked if it would apply only to pcreMatch. > Since it is part of the pattern, seems to me it could also apply to the > others, in which case all that would be available would relate to the last > match processed. For pcreReplaceCallback, might be useful in the callback > routine.
Okay, will look into it. > 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? > 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? I asked: > > Is it possible to need or get more than one markstring per match? I would > > guess not, from what you quote re api and pcre test, but I don't understand > > why not. 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?
