Of course, '$re_cond_1' may be not equal to '$re_match_1'. But I wanted to show the simplest example. Further '\1' can be used to avoid self-repeating. | [reply]
[d/l]
[select] |
> Of course, $re_cond_1 may be not equal to $re_match_1
my point is, that it has IMHO no effect at all if it's identical.
> But I wanted to show the simplest example
too simple examples can confuse :)
| [reply]
[d/l]
[select] |
too simple examples can confuse :)
Ha! Well, I'm easy to confuse. I'm not a "real" programmer--well, I've done some amazing things, but most here would be surprised at how I'd done them. I have a considerable handicap: it seems the part of my brain that should process abstract math and logic went undeveloped. I've never been able to grasp abstractions, even in the world of programming. Everything has to be concrete for me--i.e., no objects, no references, no "bless-ings"...I just don't "get" any of this stuff, and what I don't understand I cannot implement. This means I have also found very few modules written by others that I am able to use--especially ones like parsers. In all probability, there's a module out there somewhere that would help do what I need to do; but I would probably try studying it for days to figure out how to implement it, and even then may not succeed. Been there, done that. So, I just have to do my own thing. Every time.
Note that I am paid nothing for my programming--it's all volunteer to help others, and I'm internally driven to get it done, knowing no one else filling this niche.
| [reply] |
> my point is, that it has IMHO no effect at all if it's identical.
I think you're right! And my suggestion simply reduces to the same but without look-ahead :).
Too simple example even confused its author.
| [reply] |
I must say that this syntax confuses me. I am already using a lookahead to define the forward edge of the match (versus where the next match will start in the global substitution), and everything up to but not including that lookahead needs to be captured. I've never thought one could capture from a lookahead...but perhaps I'd misunderstood. I'm also using backslash lookaround assertions, because some of what is matched will be matched again (these are the false positives) and for an unpredictable number of times (fewer than 20).
I tried putting rsFalse's suggestion to use but was unable to get the match to succeed. I don't think I understand it well enough.
| [reply] |
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.
| [reply] |
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).
| [reply]
[d/l]
[select] |
