--- In power-pro@yahoogroups.com, "Sheri" <sheri...@...> wrote:
> Need more time for testing, but I ran some preliminary tests on mark and ucp > and they seem to be working. A couple of quibbles: > We said the PCRE_UCP option would be ucp. Any good reason it became usp > instead of ucp? If just a typo, please fix it, as is its counter-intuitive. Typo. Will fix next week. > Ditto for short form of mark, we said capital K, but it became little k. Will fix next week. > The short form is working in space separated variation of options, but not > working currenting in an option cluster. Yeah, I know why that would be. Will fix next week. > > Er, okay, not entirely sure I understand why *MARK can be meaningful for a > > non-match, but who am I to quibble? > Feel the same way. Okay, we're just following the docs. > Ya, up to the user to take note of whether he/she is dealing with a match. In > pcreReplaceCallback, the callback routine always will be. I suppose one also > better thoroughly test out any pattern they develop in connection with mark, > because in the docs, there are many caveats. Haven't tried it yet with > pcreReplaceCallback. Ok, whenever. > > Would it make sense to try to retrieve *MARK name when > > resultPostNoMatchAnchored comes back (if that doesn't mean > > anything to you: and after all this time it doesn't make much > > sense to me: lemme know and I'll go find out how I determine > > resultPostNoMatchAnchored) > I'm mystified, sorry. You would need to define resultPostNoMatchAnchored. > Maybe that is connected with the plugin advancing the start position and > retrying a match, in a multiple match operation. ? Hey, you think _I_ know. But I will, once I go back and read the code. I hope. Can I understand myself? Stay tuned. > If the plugin always copies the mark string, after each exec when the mark > option is set, it sounds like a lot of probably useless activity during a > multiple match operation - but this is at the user's discretion. When to > clean out or initialize regex_mark, I'm not sure. Maybe once at the start of > a regex.pcreFunction regardless if the mark option is set. ? Or should this > too be the user's responsibility? Ah, hadn't though of that. I think maybe leave it to user, it's just a one liner for them. I probably shoud clear it just before beginning a regex.pcreFunction when the mark option _is_ set though. That's when it's expected that regex_mark will be meaningfuil, and if I just leave old value hanging around, and no *MARK:NAME in encountered, regex_mark will have a value where it shouldn't.
