Ansi colour codes emitted on Powershell

[Michael-F-Bryan]

I've just reinstalled my work computer and it looks like pretty_assertions is now printing ansi codes instead of using the native windows mechanism for terminal colours. It's probably something to do with my environment, but do you have any idea why this may be happening even though cargo is able to print colours just fine?

Here's a screenshot to show the output.

cc: #1

[colin-kiegel]

@Michael-F-Bryan: Thx for the report

• Did it work before for you?
• Does it work with older versions of pretty_assertions?

[Michael-F-Bryan]

Yeah, I used to use it all the time at work although I've had my Cargo.toml set to use 0.4 for a month or so now. I just tried version 0.3.4 and powershell is still printing the escape codes, meaning it's probably something to do with my environment and not your library. This is on a clean install of Windows 10 though, so I'm not 100% sure what the difference could be.

[Michael-F-Bryan]

@colin-kiegel, what are your thoughts on swapping to the term crate for rendering colours instead of ansi_term? For some reason PowerShell has decided it doesn't want to interpret ANSI escape codes again. I can always hack around this on my side, but it seems like a better solution in the long term would be to use a cross-platform terminal library.

[colin-kiegel]

@Michael-F-Bryan Sounds like a good idea to me. Feel free to send me a PR, if you want to. ;-)

[colin-kiegel]

this should be fixed by #28 now.

[Mingun]

Unfortunately, this still an issue on some machines. I have the some problem as topicstarter -- cargo output is colored, but pretty_assertions outputs ANSI codes instead. This happens only in VSCode integrated terminal (using PowerShell 7.2.0) and only on Windows 7 (Windows 10 and Windows 11 are fine). When I run tests in PowerShell console, output is colored as expected:

Any thoughts, how to fix that?

[tommilligan]

We use ansi_term internally for string styling. My guess would be the specific terminal you're using simply doesn't support ANSI codes.

I think the most likely workaround would be to detect and disable ANSI codes if they're not supported, as here. Alternatively, we could use a different library that can already cope with the environment you describe (and use whatever colour codes are required).

I don't personally have an interest in fixing this or the environment to test it in, but happy to review any fixes from affected users.