There's also realgud which provides a unified emacs interface to several debugging backends (caveat: I've diddled with this very little personally but it's been on my list to use more).

My question is perl debugger is powerful but why many monks choose print for debug

As for why many famous programmers strive to minimize time spent in crack-pipe debugging sessions see : on Debuggers References

👁️🍾👍🦟

You'd be surprised how many people are introduced to learning Perl with an IDE doing a visual debugger run before the actual run.

Once introduced they stick with this habit of having the current line highlighted in their code.

My ex employer was more than unhappy that he couldn't run his web application inside the debugger, and I somehow never told him how to do this ;)

I also think that the introduction of lexical variables changed a lot. Before that action at a distance with global variables created a need for debugger runs with watch expressions.

Edit

But as always, it's not black and white, there are legitimate cases for debugger use.

This DON'T and NEVER rules often lead to dogmatic stupidity.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

> many monks choose print for debug, after all，-d is a part of standard perl

I think I'm one of the main debugger experts here, and I hardly ever use it for debugging.

My own code is better debugged with tests and conditional warns.

Mainly because it's easily reproduced while interactive debugger sessions aren't. I prefer sustainable investments.

Occasionally I use debug or trace if I need to take over complex foreign code.

But mostly because of bad design, testing or documentation.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

To me, not using -d is because it can’t edit in place

That's a really weird statement. A debugger and an editor are two different tools with different user interfaces. Many IDEs integrate them both.

If debugging from the command line, you can fire up the editor of your choice with e.g. system "nano $0" and then edit in place. Integrating the user interface of any editing capabilities in the debugger looks like a bad idea for me.

FWIW

The debugger has a very open interface, allows to define aliases or new commands.

The current filename and line number and code are also easily available.

See perldebug and perldebguts

It also supports piping to a "pager" app, which could be less, vi, nano or emacs, etc

So anything the OP was hinting at could be quite easily implemented.

I'm not doing to showcase it tho, because the motivation and requirements are more than fuzzy

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

The debugger can't edit files, editors edit files.

You need to combine² them if you want both.

Running emacs in the console is IMHO the closest you can do to have that look and feel of the debugger editing files.¹

Fletch's link to realgud has a screenshot , albeit for Python.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
see Wikisyntax for the Monastery}

¹) well, IIRC, there is a command to spawn an (configurable) editor on the file debugged. Maybe that's what you want?

²) that's very much the meaning of IDE