"parse state" means: how many levels deep, possibly with a backtrace printed at request (it's hard to keep track when lots of alternatives failed and/or we've recursed rather deep).
Then, $/ is the current match (if any), which makes only sense on regex exit. So that's another thing that should be added: intercepting at exit of a regex even if it didn't fail (and likewise: stop at conditional breakpoint at enter - then condition cannot not depend on $/ of course).
Additionally it would be nice to be able to show a list of current capture variables in scope, such as $0, $1, ... and named captures like eg $<foo>, $<bar>, ... (easy, as these are all just syntactic sugar for indirections into $/).
Straightforward would be to just use evil EVAL. But hey, why not? It's a debugger, at last.
"parse state" means: how many levels deep, possibly with a backtrace printed at request (it's hard to keep track when lots of alternatives failed and/or we've recursed rather deep).
Then,
$/is the current match (if any), which makes only sense on regex exit. So that's another thing that should be added: intercepting at exit of a regex even if it didn't fail (and likewise: stop at conditional breakpoint at enter - then condition cannot not depend on$/of course).Additionally it would be nice to be able to show a list of current capture variables in scope, such as
$0,$1, ... and named captures like eg$<foo>,$<bar>, ... (easy, as these are all just syntactic sugar for indirections into$/).Straightforward would be to just use evil
EVAL. But hey, why not? It's a debugger, at last.