AW: How trim: Bug in RegExp engine + docWiki

[Dave Cragg]

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