I've indeed looked into the debugger (perl5db.pl) where it's reading the caller info (near the beginning of sub DB) and I've patched my script into it right there. I didn't even have to change the $line variable as it's present with that name there already. ;-)

Of course it's still a dirty hack in its current form, but it suits me for the moment: The editor cursor indeed follows the debugger in lockstep, now even without having to insert a pre-prompt command.

Cool! :-)

Especially since the debugger now always points to the code in the editor right where it's ready to get fixed right away, just like a regular IDE. (I still have to switch windows in the editor when tracing into a different file for now, but the application window always remains in the background and updates there while I'm tracing Perl in the Terminal, so that's bearable for the moment.)

At a cursory glance I haven't seen an obvious "official" hook for this purpose in the debugger source yet, so even if my immediate need has now been satisfied, a cleaner way would still be interesting to know if somebody should happen to know one.

:) Here is some more Forking the Perl debugger - which version?, Re: RFC: debugger_trainer ... the food for thought is : trepan, ebug, Enbugger, Devel::hdb ... padre debug

good luck

Thanks for the links. There is Interesting stuff there, if not exactly usable in my environment right now. But it's interesting for motivation and instruction.

Another customization I've made is this:

o pager="cat > ~/tmp/DBGout"

with a pre-prompt action set to:

{ |y

This constantly updates the file DBGout with a dump of the currently scoped local variables.

BBEdit watches all files for changes and reloads them automatically when needed (while keeping the scrolled position in the file), so I have that file open in another window which now keeps the current variable values updated in real time while the cursor runs with the trace in the Perl source window, both with Perl syntax colouring as needed.

That's already pretty useful and quite a bit more convenient for me than the command line alone, because my code is pretty large and complex and even just the local data can be extensive as well. That makes it difficult to keep track of in the Perl debugger on its own.

It's a bit sad that I cannot create more than one watch file that way, but I guess I'll have to patch pager parameters into the debugger for that, too, so I can have separate windows for locals, globals, stack trace and so on by pushing them to separate files on every step (it's interactive anyway, so performance is not a big issue yet).