Display cause chain when alternate format is used

[link2xt]

As thiserror is complementary to anyhow, and anyhow supports {:#} format, would be nice if thiserror errors supported it too. This way in codebases that mix thiserror and anyhow errors, it would be possible to use {:#} everywhere and get cause chains printed for all errors.

[tailhook]

I also need this. Do you want me to make a PR?

[tailhook]

On the other hand, if you wrap the error into anyhow again, you can have it printed nicely without thiserror's support. Just need to make sure that when doing .downcast_ref() the original error is printed instead of downcasted.

[link2xt]

I like the approach proposed in dtolnay/anyhow#111 more than this one, actually. Just change anyhow and thiserror to print causes by default and make {} the same as {:#}.

[tailhook]

It's hard to say. I like to be able to do both. I.e. when printing vertically or when printing error messages together with backtraces.

I don't mind if {} meant with causes but {:#} meant without (i.e. opposite than what we have now). But since a lot of applications are probably relying on current behavior it's weird to change now.

Other reasons to keep current behavior:

1. {:#} is similar to {:#?} by meaning: longer more detailed output
2. We write #[error("some text with {}", values)], it's intuitive that Display shows only some text with values. If it adds : some longer thing: and another one to the output and you need {:#} "to do what I meant" it looks weird.

[koivunej]

I see #233 was closed in favor of using anyhow as the error reporter and so gaining access to {:#} but this issue is still open. I agree about the rationale of keeping thiserror clean of "reporting", but at the same time, this is a caveat we need to remember or fix after when pieces of code migrate away from using anyhow to matchable errors.

{:#} cannot be bolted on by users of the crate; a formatting fn like we have report_compact_sources, but that is easy to forget. Would a PR introducing this alternate if the impl would be calling back into thiserror on a #[doc(hidden)] function for the reporting be welcome?

[Sytten]

This would be very useful. Sometimes it is not practical to do a detour via anyhow.

[Ralith]

+1, if you're directly reporting an error produced by external code, wrapping it in anyhow or applying other custom logic is awkward and very easy to forget. In practice this has, for me, meant countless instances of errors being printed without necessary details, costing significant debugging time over the years.