Re: [pcre-dev] Partial match at end of subject

2019-07-22 Thread ND via Pcre-dev

On 2019-07-22 16:32, ph10 wrote:
The characteristic of these is that the pattern can match an empty 
string. I have now added this condition (which was easily done with no 
repeated test) and those patterns now give partial matches.




It's excellent!!

Now it can be useful to try putting into words, what exactly in applying  
to multisegment matching means "local no match" and what means "partial  
match".


--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 


Re: [pcre-dev] Partial match at end of subject

2019-07-22 Thread ph10
On Sun, 21 Jul 2019, ND via Pcre-dev wrote:

> /(?![ab]).*/
> ab\=ph
> 0:
> 
> /c*+/
> ab\=ph,offset=2
> 0:

The characteristic of these is that the pattern can match an empty 
string. I have now added this condition (which was easily done with no 
repeated test) and those patterns now give partial matches.

Philip

-- 
Philip Hazel

-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 


[pcre-dev] [Bug 2415] incorrect use of "an" in manual

2019-07-22 Thread admin
https://bugs.exim.org/show_bug.cgi?id=2415

Philip Hazel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Philip Hazel  ---
Thank you for noticing those. Although PCRE1 is pretty well frozen now, there
will probably be another release (the last?) eventually, and these are small
typos fixes, so I have applied them. I have also fixed several that I found in
PCRE2.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev 


Re: [pcre-dev] Partial match at end of subject

2019-07-22 Thread ph10
On Sun, 21 Jul 2019, ND via Pcre-dev wrote:

> New algorithm still have another parts of discussed oversight. For example it
> returns full match instead of partial in following cases:
> 
> /(?![ab]).*/
> ab\=ph
> 0:
> 
> /c*+/
> ab\=ph,offset=2
> 0:

The answer to that may lie in thinking about zero repeat items.

> Alternative suggestion don't have this troubles. It simplify calculations that
> main application must do after matching of every segment. It also have more
> common and simple (for user understanding) algorithm and can have simpler
> docs.

But it is a big incompatible change and nobody else has brought up any 
of these points in the last 10 years.

> >ND quoted /(*COMMIT)(*F)/ as a
> >simple example. Is (*COMMIT) the only way this might happen?
> 
> Not only. It may also happen with anchored patterns.

The user can find out if a pattern is anchored. If it is, there is no 
point continuing with another segment after no match on the first 
segment. 

Philip

-- 
Philip Hazel

-- 
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev