Add dbg macros

[joshka]

Feature Request

Crates

Either tracing / tracing-macros.

• tracing: if the idea seems like it's got wide appeal
• tracing-macros: if the idea seems like it should have limited appeal that should be opt-in
• impl in tracing-macros, re-export in tracing

Motivation

In Ratatui, we have a cargo-generate template which copies the macros from the unpublished tracing-macros crate into each generated template. This means that we're producing code which end users have to understand and maintain. We provide this code because the std::dbg macro is kind of useless when you're in a situation (such as exists in TUIs) where the application shouldn't randomly be able to write to the stdout at any time. The dbg macro however is useful in simply understanding the state of some intermediate calculation or state without having to change code too much. I'd like to remove that code from the templates so that we're not writing non-differentiated boilerplate though.

The tracing-macros source code has two macros dbg and trace_dbg. trace_dbg is a copy of the existing std::dbg macro, while dbg is a macro that has the same effect but instead of emitting to the stdout, emits trace events. The implicit (unstated) underlying idea here is that you should be able to take code which has dbg! calls and make it work with tracing without having to change the code aside from an import. Because tracing-macros is unpublished, there is no code which relies on this assumption.

Proposal

I'd like to suggest the opposite here. Instead of dbg being overridden, several new macros are added:

• error_dbg
• warn_dbg
• info_dbg
• debug_dbg
• trace_dbg
• (and probably as an underlying implementation detail for the above macros: event_dbg)

While this doesn't allow the calling code to easily change without having to change code, it does allow code more control over the level that these messages will be logged at. I think the benefits of this outweigh any downsides.

Alternatives

We could build these macros into ratatui rather than the templates. This seems like the wrong place to have this code as it would mean that we have to own / be opinionated about this sort of logging.

[c-git]

I think this is a great idea personally. Sometimes even in non TUI applications I'd really be happy if I could just send the info to the same places I'm sending my traces as easily as I can send it to stderr with dbg!. I second the idea of having the different versions as well. It's more obvious for one and it should only be a find replace. But most times I don't leave dbg in the code anyway.

[joshka]

Yeah, I think this is definitely applicable not just to TUI stuff. That's just the reason that it came up for me. It is likely also relevant for tauri apps where you may not see the stdout, web apps that run as CLIs where interleaving the messages with log messages would be annoying, ...