Option to create a memory-only Buffer with color detection

[kornelski]

For bevyengine/naga_oil#103 I needed to control color output when writing to Vec<u8>/String, but I couldn't find a way to do this reusing termcolor's color selection logic.

I think I could use Buffer, because it can return its contents as Vec<u8> without printing it. However, there isn't any way to create a Buffer other than BufferWriter::stderr/stdout().

[BurntSushi]

I'm not sure this is feasible. A Buffer's internal representation is tied to the kind of coloring that will be done with it. On Unix this isn't very interesting, but on Windows it depends on whether virtual terminal processing is enabled on the output device or not. That is in turn why you can only get a Buffer if you have some connection to the output device. You can't just materialize it from nowhere unfortunately.

In your patch, it looks like you're trying to replace code that assumes ANSI color escape sequences. That's probably where your trouble is. The termcolor API is specifically designed in a way that it supports both ANSI and the legacy Windows console coloring APIs. With just ANSI escapes, you can embed the directives into a memory buffer and just dump them to the output device and rely on the terminal emulator to interpret them in-band. But with the Windows console, the application has to actually interact with the console directly and synchronously to change the colors.

The main alternative point in this design space is to accept ANSI everywhere, and for the Windows console, write an interpreter for the ANSI escapes that translates them to console API calls. But termcolor doesn't and probably will never do this. I think anstream takes this approach, which might give you a better experience.

To wrap up, one very important thing about termcolor is that you probably shouldn't use it unless you need to support Windows console APIs. And even if you do, you might prefer anstream.