--- In [email protected], "silvermoonwoman2001" <sheri...@...> wrote:
>
> > In forgot to alter the pattern you provided for matching
> > replacement patterns, now
> >
> > LPSTR pszPatternCaptures =
> >
> > "(?s)\\\\\\\\|\\\\\\$|\\\\[0-9]|\\$(?:U|u|L|l|T|t|X|x|Y|y|Z|z)?\\d{1,3}|\\$(?:U|u|L|l|T|t|X|x|Y|y|Z|z)?<[A-Za-z_1-9]{1,32}>|\\$\\#";
> Lets try it this way, it should be a bit more efficient:
>
> "(?si)\\\\\\\\|\\\\\\$|\\\\[0-9]|\\$[LUTXYZ]?(?:\\d{1,3}|<[A-Z_1-9]{1,32}>)|\\$\\#";
Take your word for it, ta.
> Also, please advance the plugin version and date.
Will do.
> The new letters are not being invalidated in the absence of utf8 plugin
> option. I think that's ok; as is they work even when the new internal pattern
> utf8 option is used. It will be the user's responsibiltity to ensure L,U,T
> and X,Y,Z are used only where appropriate. If either is used on incompatible
> subject data, it can result in corrupted output.
Okay, you get to add all that to docs.
> In initial tests they seem to be working fine. Also, the utf8 plugin option
> is now working as a multipurpose option (compile and accept-unicode-handles).
Ok, let me know if ready to roll with new version.
