On 2019-07-24 15:51, ph10 wrote:

If I understand you correctly, your proposal would mean that every
non-anchored pattern would give a partial, empty-string, hard partial
match at the end of a non-matching segment, and never return "no match".

Yes. And I like this idea.
With it we could operate in terms of matching a WHOLE subject that is
definitely exactly what we are interesting in.

When current segment can't brings us neither "match", nor "no match"
information about whole subject, then result is "indefinite" (this is a true meaning of thing that we now called "partial hard match"). In this "indefinite" situation we
wants to know only one thing: what part of current subject must be keeped
and afterwards joined to next segment.


I do not like this idea. This is how I see it:


I understand your idea. It replaces a true goal (matching a whole subject) with auxiliary goal that we sure will lead us to the ultimate one. This auxiliary goal don't worry directly about whole subject matching but worry about can or not current segment be part of a match. But getting definitely answer to this question is quite difficult due to some "tricky" usecases. And I guess now we take into account not all possible cases. And I don't sure that we can easily take it all. But imagine that we definitely detect that current segment can't be part of a match. Now we must additionally find out: is that due to whole subject no match or not. So user must check after each "no match", is the "no match" false-commit or is pattern anchored.

So to achieve those auxiliary goal we brings complexity to understanding, docs and code. After every nomatch we force user to do what he could not do.

But all this complexity is not needed as we don't try to find answer to the question: can or not current segment be part of a match.


PS
And some bad things are happen now due to max_lookbehind. But it's beyond my strength to write so large english texts at once. May be after we get acceptable decision in this topic...

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

Reply via email to