The terminals in question do not support color. We used to return Ok(false) when a program tried to use an unsupported attribute but we now return an error (Err(Error::NotSupported)). This patch makes it possible to check supports_color up front to avoid running into this issue.
I'm asking for a review because I don't know if supports_color should imply supports_reset or if we should have the programmer call supports_reset() && supports_color(). Can you think of any cases where one might care about supporting terminals that support color but not resetting those colors to their defaults? Do any such terminals even exist?
Once I get this merged and I cut yet another release, cargo can call term.supports_color() after creating the terminal to make sure the terminal will actually be useful.
alexcrichton
commented
8 years ago
This makes it easy to determine if the terminal supports color.
/cc @cmr, @alexcrichton
This is part of fixing https://github.com/rust-lang/cargo/issues/2338#issuecomment-177268195.
The terminals in question do not support color. We used to return
Ok(false)when a program tried to use an unsupported attribute but we now return an error (Err(Error::NotSupported)). This patch makes it possible to checksupports_colorup front to avoid running into this issue.I'm asking for a review because I don't know if supports_color should imply supports_reset or if we should have the programmer call
supports_reset() && supports_color(). Can you think of any cases where one might care about supporting terminals that support color but not resetting those colors to their defaults? Do any such terminals even exist?Once I get this merged and I cut yet another release, cargo can call
term.supports_color()after creating the terminal to make sure the terminal will actually be useful.