@FryAmTheEggman without looking at it in detail, are you expecting the groups inside the lookahead to backtrack? that won't happen. lookarounds are atomic

so instead you'll want to match the ABA first without a lookaround and then do the rev(B) part in a lookbehind from the end of the string

best idea I have at the moment is tio.run/…

there might be a way to avoid the double lookaround, but I'm not sure

@FryAmTheEggman btw, I'm finally starting work on that major update we talked about months ago (unifying how all the stages work and then implementing a good bunch of features on top of that).

@MartinEnder Ahh, I had guessed that, but I couldn't work out why it was working in the other cases then... Oh well thanks for the help!

Also the update sounds exciting!

feel free to post it anyway :)

as for the update, I've been planning a ton more features actually. this will probably end up being 1.0

one thing I'd like to figure out is to make the non-matches accessible to manipulation as well

I think it'll be most useful for transliteration mode (transliterate everything that wasn't matched), but I'm sure there'd be uses for other stages too

That would be handy, particularly if you could also use replace to delete unmatched stuff

yes something like that

there'll also be substitution elements to access adjacent matches/non-matches

e.g. $<1 to get the first group of the match/non-match to the left

Hmm, I don't think I quite follow, to the left of what?

of the current match you're replacing

(or non-match)

e.g. if you're replacing a match then $<& might insert the stuff between the current match and the one to its left

Ohh, ok, so if I did \d+ and $<1 I would rotate all the numbers in the input left one?

(because it would refer to the $& of the non-match to its left)

Err, right one

I haven't decided 100% on how matches and non-matches will interact here yet

but in general if you match something then the string will be partitioned into alternating segments of matches and non-matches

it would be good to be able to refer to both the preceding segment of the opposite type as well as the preceding segment of the same type

True, maybe that could be a config thing in general? With it defaulting to one behaviour then being configurable

I might just add syntax for both

e.g. $<& might be one and $[& might be the other

I'm also considering to allow repeating them for further-away references like $<<<& but having to use $<<& to get at the next match seems painfully expensive, which is why I'll probably support two different elements there

also thanks for the number rotation example. I hadn't considered them to be cyclic so far. that would also be something that should probably be either configurable or have some additional syntax element (whether or not you want it to be cyclic)

Yeah two different tokens would work fine, and having a way to make it look farther is also good

It could maybe use a number for bigger amounts, like $n<&?

oh yeah that probably makes more sense

although that's ambiguous

If it would work liked $* it could be used in some funky ways

Oh right, I guess maybe n$*<&?

Oh nope that's ambiguous too

Well, there are plenty of characters, I'm sure something clean will work out xD

yeah, I'll have to think about, but thanks for the input

the other problem with having both matches and non-matches is how various flags interact with these. currently, only O has ^ (reverse matches after processing). it's something I'd like to add to all stages, but a) it might be useful to be able to reverse non-matches or both, b) for some stages reversing matches is a bit pointless (primarily split)

and grep/anti-grep, where the matches just mark lines to be kept/discarded

it's still proving to be the most obnoxious flag in unifying how stages work :D

Hmm, you could make ^ apply to grep/antigrep apply to the output lines? But it's not particularly clean/related

yeah that would be most useful, but it would be a weird special case unless I just implement ^ manually for each stage in the most appropriate way