I then considered the difference to 'n' too miniscule to bother with it.

Others won't.

is perl5db.pl required to be backward compatible to Perl 4.x

Well of course not. It uses lexical variables for starters. You are looking at possibly the oldest, continually tweaked file in the Perl distribution though. It has enough cruft and differing code styles and idioms without adding one more.

Fixing 'n' to do what it always should have with map/grep/sort would be a very welcome change. As already pointed out, there is no loss of functionality. Instead of 'n' and 's' both stepping into the map/grep/sort (which is almost never what I want to do), 's' does the old behavior and 'n' does something much better.

Of course, I sent in a near-trivial patch to fix "o warn=0" and got quite bizarre responses from p5p and I've come to expect bizarre responses from p5p so if your prediction is correct it wouldn't be anything "new" from my perspective. But I still think it would be a senseless form of backward compatibility.

Perhaps I should point out that my patch for "o warn=0" restores backward compatability with "O warn=0" from before the whole debugger interface was jumbled around for some reason. It might motivate somebody to apply my two-line patch due to the occasional extreme devotion to backward compatability. But I doubt it.

- tye        

Thanks,

I am trying to consider corner cases just now. The weak part in my patch is the correct detection of grep/map/sort, I think.

Example:

$c++; $d++; $e++; print 'map';
[download]

would currently not stop four times when single stepping with my modified 'n' command, which is not yet ok.

BTW: Where can I see your patch?