Hi!

I know it doesn't overload it for the command line, because it makes no sense to show HTML if HTML can not be rendered (ie, if html_errors is off).

In Xdebug 2.2 var_dump is already overloaded on the CLI if you set xdebug.cli_color=1 so all the xdebug.var_displaymax* settings will work (and you get a coloured output!).

Let me know if you meant something else.

Derick

Why is var_dump overloading dependent on the html_errors and xdebug.cli_color setting at all? If I understand you correctly (please tell me if I'm wrong), var_dump would still not be overloaded in the CLI if both these settings are off. A possible use-case for that is if I want to capture the xdebug's var_dump output on the CLI and post-process it in some way. In that case I don't want CLI colors.

I do this with Phing for example. I have added a couple of debug flags to my Phing build script that var_dumps various objects. Phing captures these in build properties which are used (or echoed) elsewhere in the build script.

I think ideally, var_dump overloading (and usage of the xdebug.var_display_max_* setting) should only depend on xdebug.overload_var_dump. html_errors and xdebug.cli_color should only determine how the output is rendered, not whether overloading is used.

I think that would be much more useful. With all the new heavily object-oriented PHP 5.3 frameworks (like Symfony 2, Doctrine 2, Lithium, etcetera) PHP's regular var_dump is quickly becoming useless because it just dumps in infinite recursion. If fact, I even have XDebug enabled on my production server just so I can use the xdebug.var_display_max_* settings.

Duplicate of 0000457, which is implemented for Xdebug 2.2.0 already.