Improve color support detection

[spenserblack]

My initial approach was admittedly driven by eagerness to address the immediate issue, and I appreciate you taking the time to refine the implementation.

Regarding Windows Terminal detection, as you mentioned, we could always enable true color support on Windows.

About the set override functionality, I'm thinking whether we need to modify some function names in the existing ShouldColorize in control.rs and make some optimizations. I want to put the truecolor support set override into control.rs, but there are already functions named set_override and unset_override, which makes it difficult to distinguish between TrueColorSupport and ShouldColorize.

I also want to add that this isn't just a Windows-specific issue. On Linux, we might encounter similar situations where some terminals support ANSI 256 colors but don't explicitly indicate truecolor support. In such cases, it would be more appropriate to convert truecolor to ANSI 256 colors rather than falling back to 8 colors, as this would provide a better color representation.

It will take some time to perfect these changes and ensure everything works as expected. Thanks.

Originally posted by @cnlancehu in #194 (comment)

[spenserblack]

Continuing conversation in this issue for better visibility.

Good point about how should_colorize can be misleading. I'm thinking that color support should be changed from a boolean (or a group of booleans) to an enum. The levels would range from "true color" to "none". This can be made non-breaking by deprecating some utilities and changing up their internal implementation, I think.

I think it would be best to split this up into multiple PRs. First one would be to change from boolean to enum implementation, and we can work from there.

@cnlancehu You're welcome to try this out if you want. Otherwise I'll probably try to refactor, deprecate, etc. when I have time.

[cnlancehu]

I will try to do that if I have spare time, although I might lack it due to academic pressure.
A temporary solution to fix it is to manually set the environment variable COLORTERM to truecolor.

As a beginner, I am not proficient in Rust and still need your guidance and assistance. Thanks.

[spenserblack]

No problem and no rush 🙂

You can start with a draft PR with some skeleton code, e.g.

/// This is a doc comment that describes what I want `my_new_fn` to do.
pub fn my_new_fn() {
    unimplemented!()
}

And I can guide you through implementation.

[cnlancehu]

I just created a fork and we can start from here
In this commit I did some breaking changes including

• Implemented better terminal color-support detection
• Deleted closest_color_euclidean and added truecolor_fallback_to_ansi16 truecolor_fallback_to_ansi256
• Implemented better override function and finished its example
• Rewrote ShouldColorize ColorLevel enums
• Deleted some outdated tests

The documentation comments are already written.
But I haven't tested its functionality or the visibility of the APIs yet. I'll do that later.

I think it's better to delete the original deprecated codes directly, rather than using #[deprecated], and merge the changes in a new major version due to the significant changes to the API.

During weekdays, I only have time at night (morning in the US), so my responses may be slow. I apologize for any inconvenience.

[spenserblack]

During weekdays, I only have time at night (morning in the US), so my responses may be slow. I apologize for any inconvenience.

No need to apologize, and thanks for your hard work!

I'll review the branch later. I'd like to take some time and consider ways to make the changes non-breaking (#[deprecated] helps avoid breaking changes by encouraging changing usage instead of forcing changing usage). If you can make a draft PR, that will be helpful for discussing changes.