Looking at the code, it definitely has no Windows specific support. Windows has a number of different cases:
- For terminals like MinTTY (e.g., what Cygwin comes with IIRC), ANSI escape codes on Windows will “just work” exactly like they do on macOS or Linux.
- For other terminals in Windows (like cmd.exe or PowerShell), ANSI escape codes never “just work.” Coloring via the Windows console APIs will, however, always work.
- As of Windows 10, you can put Windows console based terminals into a virtual terminal processing mode. Once this is enabled, ANSI escape sequences will “just work” like they do everywhere else.
colored crate neither uses the Windows console APIs, nor does it put the console into VT processing mode. Therefore, it cannot work on Windows. This is further evidenced by this bug report. So in this case, I’d say the README is wrong.
ansi_term supports all of the above except for coloring via the console APIs. Therefore, it works in most situations you might want.
termcolor goes a step further and provides support for coloring using the console based APIs, which means you get colors on Windows 7, which isn’t possible with
ansi_term. The cost is termcolor’s crude API. Namely, doing coloring with the console APIs requires synchronous communication while you’re printing to the screen, where as ANSI escapes are just in-band with the output itself. With the latter, it’s trivial to put ANSI escape sequences inside strings and manipulate them, and then just send them to the output device like anything else. There’s a lot of flexibility there. With console coloring, you need to go out of your way to do special things when you print stuff. (Either with an explicit cross platform API, or via an ANSI escape code interpreter, or similar.)
Folks seem to really like having a highly convenient API for coloring, and as long as you’re OK with dropping Windows 7 support, then that’s a good way to go. But not everyone is OK with dropping Windows 7 just yet, and thus, you have a splintered ecosystem.