Fix non-Windows terminals assumed to always support 256-color

[mislav]

Backports https://github.com/cli/cli/pull/6356

[heaths]

Wouldn't this completely break alternate screen buffers on *nix then? There are other ways of detecting whether VT sequences are supported:

• Using tput e.g., https://unix.stackexchange.com/questions/450365/check-if-terminal-supports-24-bit-true-color
• https://github.com/microsoft/terminal/issues/1040#issuecomment-1043650915

See https://github.com/cli/cli/pull/6356#issuecomment-1276773296 for more information.

[heaths]

I submitted https://github.com/cli/cli/pull/6435 to restore behavior without impacting this PR, since the change was only to restore the original behavior without assumptions of VT support this change inferred. This PR would actually be a good fix, but long-term support for various color or other VT support might be good to add to go-gh. See https://github.com/cli/cli/pull/6435#issuecomment-1277776665 for possibilities.

[mislav]

@heaths I don't see how this can break alternate screen buffers on *nix. There is still an issue with that in the CLI repo, I agree, but we will resolve that in that repo.

[heaths]

Agreed. Please see my latest comment.

[heaths]

To clarify my comment about VT support, I was suggesting maybe something in this module could define, but perhaps that would best be in one of @mattn's many term modules, if it isn't already (I couldn't find one).

[mattn]

Can I help you? If you can explain how to reproduce the problem, I can fix that.

[heaths]

Mainly, with all the terminal modules you have, was wondering if any of them might be a good place to put better VT support detection into. See https://github.com/cli/cli/pull/6435#issuecomment-1277776665 for some thoughts. We've also been wrestling with some of these ideas for Windows Terminal as well. If you think one of your modules might be appropriate, maybe you or I could open an issue and discuss more there.