Improve interoperability with `std::fmt` traits
yaahc opened this issue · 2 comments
Right now I'm trying to write an error reporting library that colorizes the output with color-backtrace and termcolor. I got the changes necessary in color-backtrace to print to a string rather than directly to stdout, but the changes required that we allocate temporary buffers and go through the Ansi struct which can then be converted to a String.
This seems like a less than ideal API, I understand that part of the issue is how older versions of windows handle changing colors with syscalls and that termcolor is just providing the most uniform API that covers all the targeted platforms. It would be nice however if there were some alternative ways to colorize output that ignore these older platforms and just add the necessary color codes to the output.
If it helps at all this comment notes that all versions of windows that are currently supported by MSFT support VT100 athre0z/color-backtrace#27 (comment)
I don't have strong preferences about what the API looks like, and I'm happy to write the PR to add the features I need, just let me know if you're interested and how you'd like it implemented and I'll get right on it.
It would be nice however if there were some alternative ways to colorize output that ignore these older platforms and just add the necessary color codes to the output.
I think that's exactly what Ansi is.
If it helps at all this comment notes that all versions of windows that are currently supported by MSFT support VT100 athre0z/color-backtrace#27
If you don't care about supporting older versions of Windows, then I probably wouldn't recommend using termcolor. termcolor was literally designed, from the ground up, to make it possible and fast to do platform independent coloring in a multi-threaded fashion. If you don't need to support the old Windows console APIs, then there are substantially simpler APIs.
There will probably come a day when I no longer want to support the old console APIs. I don't know when that day will come, but it's not today. And when it does come, I'll likely deprecate termcolor (or hand off maintenance to someone I trust) and then switch to something like the ansi_term crate.
For that reason, I don't see a compelling reason to add more APIs for cases that don't care about the Windows console. It just doesn't make a lot of sense given the goals of this crate and the available alternatives.
didn't know about ansi_term, this looks perfect, ty