You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The term /{a(?!b)} matches a but only if it the next match wouldn't be b. This can be useful to avoid accidentally absorbing content that will stymie later matches. e.g.: "-"? "->" will never match -> because the first term absorbs the -. This can be fixed by not matching - when it's followed by >: /{-(?!>)}? "->".
Unfortunately, RE2 doesn't support any form of look-aside assertions. However, the above special case can be faked by matching ab|(a) and succeed only if the capturing group has something in it. This should be recursively generalisable:
a(?!b)c(?!d)e(?!f) = ab | ( ac(?!d)e(?!f) )
= ab | (?: acd | ( ace(?!f) ) )
= ab | acd | ( ace(?!f) )
= ab | acd | (?: acef | (ace) )
= ab | acd | acef | (ace)
In simple terms: eliminate failed pathways first, then match the successful pathway. If a...f themselves contain lookahead assertions, they can probably be rewritten recursively, though some thought must be given to capturing groups.
Positive lookahead, a(?=b) can also be faked, though the value proposition isn't as compelling. The technique is also different: match a(b) but, after a successful match, return the input state back to the beginning of b.
In terms of sequencing the work, supporting a single look-ahead at the end of the regexp would be a very useful MVP.
The text was updated successfully, but these errors were encountered:
The term
/{a(?!b)}
matchesa
but only if it the next match wouldn't beb
. This can be useful to avoid accidentally absorbing content that will stymie later matches. e.g.:"-"? "->"
will never match->
because the first term absorbs the-
. This can be fixed by not matching-
when it's followed by>
:/{-(?!>)}? "->"
.Unfortunately, RE2 doesn't support any form of look-aside assertions. However, the above special case can be faked by matching
ab|(a)
and succeed only if the capturing group has something in it. This should be recursively generalisable:In simple terms: eliminate failed pathways first, then match the successful pathway. If a...f themselves contain lookahead assertions, they can probably be rewritten recursively, though some thought must be given to capturing groups.
Positive lookahead,
a(?=b)
can also be faked, though the value proposition isn't as compelling. The technique is also different: matcha(b)
but, after a successful match, return the input state back to the beginning ofb
.In terms of sequencing the work, supporting a single look-ahead at the end of the regexp would be a very useful MVP.
The text was updated successfully, but these errors were encountered: