On Sat, 14 Jul 2018, ND via Pcre-dev wrote:
> PCRE2 version 10.31 2018-02-12
> /(*NO_START_OPT)\A(?>(*:1)a)((*:2)x|)/mark
> ab
> 0: a
> 1:
> MK: 1
>
> Resulting mark is "1" when no backtracking is allowed to it.
It just remembers "most recent mark" in the backtracking frame.
Philip
--
Philip
On Thu, 12 Jul 2018, ND via Pcre-dev wrote:
> And one more thing should also be clarified in docs:
> MARK name unlike MARK position is saved outside assertion or atomic group:
I have tried to clarify this.
Philip
--
Philip Hazel
--
## List details at
On Sun, 15 Jul 2018, ND via Pcre-dev wrote:
> PCRE2 version 10.31 2018-02-12
> /(?>a(*:1))(?>b(*:1))(*SKIP:1)x|.*/
> abc
> 0: bc
>
>
> If MARK in atomic don't matter for SKIP then why result is "bc" and not "abc"?
> If MARK in atomic matter for SKIP then why result is not "c"?
This was an
On Sun, 15 Jul 2018, ND via Pcre-dev wrote:
> PCRE2 version 10.31 2018-02-12
> /(?>a(*:1))(?>b(*:1))(*SKIP:1)x|.*/
> abc
> 0: bc
>
>
> If MARK in atomic don't matter for SKIP then why result is "bc" and not "abc"?
> If MARK in atomic matter for SKIP then why result is not "c"?
This does look
And one more possibly bug:
PCRE2 version 10.31 2018-02-12
/(?>a(*:1))(?>b(*:1))(*SKIP:1)x|.*/
abc
0: bc
If MARK in atomic don't matter for SKIP then why result is "bc" and not
"abc"?
If MARK in atomic matter for SKIP then why result is not "c"?
--
## List details at
On 2018-07-14 15:12, ph10 wrote:
Feel free to look at the code and suggest patches. However, I don'tthink
is is easy.
Sorry. I'm not ะก programmer.
It doesn't have to do anything
special when it passes a (*MARK:NAME) other than record a backtracking
point. Then when (*SKIP:NAME) is
On Sat, 14 Jul 2018, ND via Pcre-dev wrote:
> It seems instead of maintaining only MarkNames PCRE can maintain a table with
> MarkName-MarkPosition pares. And so not have need to backtrack to access MARK
> position data. And not loose MarkPosition information.
Feel free to look at the code and
On 2018-07-14 07:16, ph10 wrote:
>> Why it need to backtrack?
> Why not do a "bumpalong" advance to the next starting character strait
away?
It has to backtrack to the *MARK because that is where the bumpalongdata
is remembered. There may be many *MARKs, each with a differentname. You
On Sat, 14 Jul 2018, ND via Pcre-dev wrote:
> On 2018-07-13 16:08, ph10 wrote:
> >When SKIP has a name, it backtracks until it hits a MARK with the samename.
> >
>
> Why it need to backtrack?
> Why not do a "bumpalong" advance to the next starting character strait away?
It has to backtrack to
On 2018-07-13 16:08, ph10 wrote:
When SKIP has a name, it backtracks until it hits a MARK with the same
name.
Why it need to backtrack?
Why not do a "bumpalong" advance to the next starting character strait
away?
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
On Fri, 13 Jul 2018, ND via Pcre-dev wrote:
> The SKIP verb don't need backtracking after it fires: there is bumpalong and
> new match. If MARK position is saved then there is no problem for engine to
> discard current matching and start new matching at saved position without any
> backtracking.
On 2018-07-13 07:23, ph10 wrote:
On Thu, 12 Jul 2018, ND via Pcre-dev wrote:
And one more thing should also be clarified in docs:
> MARK name unlike MARK position is saved outside assertion or atomic
group:
The MARK position *is* saved; it's just that there is never a backtrack
into an
On Thu, 12 Jul 2018, ND via Pcre-dev wrote:
> And one more thing should also be clarified in docs:
> MARK name unlike MARK position is saved outside assertion or atomic group:
The MARK position *is* saved; it's just that there is never a backtrack
into an atomic group, so that data is never
On 2018-07-12 07:25, ph10 wrote:
The (*MARK) is inside the assertion. That is what matters. I haveupdated
the documentation to say this:
The search for a (*MARK) name uses the normal backtracking mechanism,
which means that it does not see (*MARK) settings that are inside
atomic groups or
On Wed, 11 Jul 2018, ND via Pcre-dev wrote:
> I seen this docs before.
> But in example verb not appears inside assertion. It appears after it.
The (*MARK) is inside the assertion. That is what matters. I have
updated the documentation to say this:
The search for a (*MARK) name uses the
On 2018-07-11 16:27, ph10 wrote:
This already appears in the docs:
However, when one of these verbs appears inside an atomic group or in
an assertion that is true, its effect is confined to that group,
because once the group has been matched, there is never any
backtracking into it.
I
On Sun, 8 Jul 2018, ND via Pcre-dev wrote:
> It seems if mark name is defined in assertion then SKIP with this name is
> ignored.
> May be a little docs clarification about this needed.
This already appears in the docs:
However, when one of these verbs appears inside an atomic group or in
Good day.
PCRE documents about SKIP verb with NAME:
"When (*SKIP) has an associated name, its behaviour is modified. When it
is triggered, the previous path through the pattern is searched for the
most recent (*MARK) that has the same name. If one is found, the
"bumpalong" advance is to
18 matches
Mail list logo
