On 25 Oct 2005, at 20:19, Mark Wieder wrote:
Ken-
Tuesday, October 25, 2005, 10:28:36 AM, you wrote:
Actually, it *should* support the full form of PCRE, since that is
the
library that was used when the put it into the engine. The bugs
you identify
above are all enhancement requests, so they are not representative
of actual
bugs with the engine - in fact the only other two bugs I could
find were
related to docs and not PCRE support at all.
So AFAICT we have a full and complete PCRE implementation here,
with no
'real' bugs associated with it.
Well, my BZ #2805 was filed as an enhancement because I realize that
runrev implements *some* of the regular expression characters in the
filter command, but not all. I realize the matchText function handles
more of them, but whether this inconsistency is a bug or an
enhancement request is a matter of semantics. If the engine implements
the full PCRE set but I can't get to it using the syntax that the
builtin commands will accept, it doesn't do much good from a scripting
perspective.
I don't think it's just a matter of sematics.
matchText doesn't just handle "more of them"; it effectively
handles "all of them".
The "filter" command doesn't claim to use regualr expressions. (only
matchText, matchChunk, and replaceText do) The docs for "filter" use
the term "wilcard expression", and in fact, a much richer set of
wildcards are allowed in filter now than used to be the case.
To me, there's a big difference between "Wouldn't it be nice if the
filter command used the full RegEx syntax in the same way as
matchText?" and "Rev's regEx implementation is a sparsely-documented
subset of PCRE compatible
syntax and that subset can change at any time."
Cheers
Dave
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
