http://qs1969.pair.com?node_id=11129282


in reply to Re^3: How to enforce match priority irrespective of string position
in thread How to enforce match priority irrespective of string position

you can separate the "condition to match" (in the lookahead) from the actual match-pattern.

Point is that a failed partial match might move the pos forward, but if the condition fails pos won't be changed before trying the next or-alternative.

rsfalse might provide/link an example.

Cheers Rolf
(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery

  • Comment on Re^4: How to enforce match priority irrespective of string position

Replies are listed 'Best First'.
Re^5: How to enforce match priority irrespective of string position
by rsFalse (Chaplain) on Mar 07, 2021 at 15:01 UTC
    I guess OP might try use his '(.*?)' within every branch to achieve priority matches. But as he wants to capture it, he will use more capturing groups, e.g. 1+2, 3+4 and 4+5, where $1, $3 and $5 is what '(.*?)' capture. Or he may use '(?|...)' group for parallel numbering (https://perldoc.perl.org/perlre#(?%7Cpattern).
      Frankly, I don't know what OP really wants. at least I think so ... :)

      As is said he should provide test cases. (If he can't, this would mean that he doesn't know it either. ;)

      And we are at risk to get lost in speculations.

      Cheers Rolf
      (addicted to the Perl Programming Language :)
      Wikisyntax for the Monastery

        As is said he should provide test cases.

        I added another illustration to the OP to attempt to clarify.

        Blessings,

        ~Polyglot~

      I have only a few "branches" (alternations) for the forward-looking assertion. But how would I put a capture group there? In any case, I've made several attempts at this now with no success. For some reason the match always ends at the earliest possible alternation, apparently recognizing the (.*?) in the separate branches as being equal. Going to an unqualified greedy capture would not work either, as that would potentially slurp entire paragraphs instead of sentences until a match would be found--combining chunks that should remain separate.

      For my part, any way that will do the job works for me. I don't mind, for a one-time-use script like this, writing pages of messy looking code that is inefficient, ugly, whatever--if so long as it would get the job done! So having a large number of capture variables is a non-issue. I've sometimes gone above 30 on those for a job of this nature! But in this particular case, that is not going to solve the problem.

      Blessings,

      ~Polyglot~