Display vs. Debug

[KillTheMule]

Hey!

First of all, thanks for this lib! I'm using neovim-lib, which builds upon this :)

While thinking about an issue I opened at neovim-lib, I went to look at the debug/display implementations for Value. I noticed they're basically the same, and this is somewhat connected to my issue. The short version is that I'm pushing large data over msgpack, and the debug representation taxes my log quite a bit.

So, is this intentional that display/debug are so similar? I don't know what's best pratice here, but to me it seems they should offer something different, otherwise why have both? I'm kinda imagining that one of both should not fully print the value recursively, but output information on the Value, i.e. the type, maybe the length (if applicable). I'm not sure which though, since I imagine display should be used for human readability, and in my case a 67MB string on one line isn't really that. But not outputting the contained value on display, but doing so on debug sounds weird as well.

I do not have a real proposition, but would like to hear your opinion on that. I'd want to link https://doc.rust-lang.org/std/fmt/#sign0, which shows that more fine-grained behaviour would be possible, too. I'd be open to making a PR for whatever-we-figure-out-is-best (if it comes to that, no pressure, I'm just interested mainly).

[3Hren]

Hi!

Debug is for debugging. There must be the most full info to be able to debug whatever's going on. Also it's important, that the compiler auto-generates it using derive.

At the opposite, Display prints out the most convenient output of a Value. I made it similar to JSON (it also prints the entire value regardless of its size and netsing).

You can always wrap Value into a new type and implement Display yourself if you need specific output.

[KillTheMule]

Thanks for your answer :)

You can always wrap Value into a new type and implement Display yourself if you need specific output.

The thing is it's not really in my hands, it's in an intermediate library, and I'll have a hard time convincing the author of that lib to do custom stuff only for me. I get what you're saying, and understand it to a certain extent, but the whole "system" isn't really made for large blobs of data.

Could I maybe convince you to accept an implementation of debug pretty printing that avoids the payload? That way, callers can directly choose themselves (by using either {:?} or {:#?}), and I could maybe convince the library's author to make different debug printings available behind a configuration flag. That would mean implementing Debug by hand, though, and overriding the "standard" debug pretty printing.

The more I think of it though, the more I think it could be a config flag for the other library to have a condensed debug print. I'll bring that up, thanks for your time!