AW: How trim: Bug in RegExp engine + docWiki

[Ken Ray]

>> 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."

Agreed. Which is why it is an enhancement suggestion to the filter command.
My guess is that the filter command preceded the
matchText/matchChunk/replaceText tokens and so used a limited form of
wilcard expressions. Personally, I'd *love* for everything that used
"wildcards" or "regular expressions" all used the same full-bodied PCRE
engine... 

Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: kray at sonsothunder.com