From time to time, I wonder why n doesn't jump map, grep, etc.
Everytime a code block is entered, the Perl core delivers control to the debugger. Now it seems to me, when 'n' was created, some additional logic has been implemented, in order to shortcut the execution of subroutines, but not code blocks (like from map/grep/sort) in general.
So I could even file a bug report :-)). That depends on your viewpoint, of course.
Update: I think the patch could be made better, if the general problem of shortcutting code blocks is solved.
Then also operators (any, all, ...) from List::Utils and friends could be stepped over. So, I will look into it again.
Stay tuned...
Therefore, I suggest that you try p5p, explain them grinder's comments about backwards compatibility and the idea of using N as an alternative.
That is a great suggestion, thanks. I will ask them how serious they value backward compatibility in this case.
Either it can be changed, or there will be a new command then.
I will also try out, if the '=' alias can be used to redefine 'n'.
Finally, the 'Perl Hacks' book has hack #59 for writing your own debugger commands or modifying existing ones. But since many (most?) users want the change, it might be better to change it once in the debugger source.
| [reply] |
Oh, I think it's a good idea to change the source. In terms of backward compatibility you've still got 's' (step into), while the 'n' (next statement) is always a pain when 'n'-ing over sort and map blocks. Of course you can 'c' (continue) to a new location (line), but then you have to stop, break your flow, and work out where you want to go specifically. It's nice to see someone prepared to delve into those murky depths to fix this behaviour to be more intuitive at last.
R.
| [reply] |
| [reply] |
