Suggest patching 'colors' field for 1 << 24

[jquast]

suggested by @vxgmichel from vxgmichel/gambatte-terminal#41 (comment)

'colors' field in a terminfo binary database file was historically 16-bit limited, but can "upgraded" to 32-but, https://github.com/jquast/ttyscan/blob/master/ttyscan.py#L510

I guess the 'xterm-direct' and many other '-direct' variants, were designed to ensure you would use it only for possible truecolor support indicated in 'colors' field for "modern" applications, 32-bit and newer.

Some thoughts/options,

• jinxed could patch 'colors' to be 24-bit, if they have any -direct ancestors that describe 24 bit color in setaf/ab, or, can be patched in terminals.toml when known to support it .. kitty, contour, etc.
  • I think xterm-direct and xterm-256color-direct may be exceptions to the rule, although XTerm supports truecolor, the many terminal emulators sharing this TERM may not. Whereas "rio", "contour", "kitty", etc. most certainly do.
• jinxed could also generate and re-export "-direct" variants, the code generation should correctly make small "inheritance" files if the source file is described as such,
  • And then everything is on blessed's responsibility to use jinxed to "merge" or update the setaf/setab/colors/etc. fields using the overlay method recently added

let us know what you think @avylove

[avylove]

What do you think the best approach is, not just in the context of blessed, but for anyone using Jinxed as an alternative to curses?

All the color support detection is in Blessed now, right? And some of those criteria are easy for Jinxed to check (environment variables, windows version) and others aren't as easy (XTGETTCAP), correct? Though we could always do best effort and allow an external override of that detection mechanism.

[jquast]

I was wondering what you would think, it is a suggestion, we can do everything in blessed and maybe we should -- I wondered that jinxed could patch the return value of the colors field to be 1 << 24, because it is free from 16-bit legacy compatibility, and that it is able to make that determination by parse of terminfo.src.

That TERM=rio, contour, ghostty etc. can determine truecolor by nothing more than their name. Might as well also check for COLORTERM.

From the perspective of, "How can I know this unique TERM type supports truecolor", blessed does not have access to terminfo.src or any -direct capabilities, so it will have to be a list of hardcoded values, but that's not too bad, certainly the least amount of code so probably better long-term maintenance and fewer jinxed releases.

[avylove]

So we have a few scenarios, am I missing any?

• The kind passed in or determined by the environment is always 24-bit

  • The terminfo in Jinxed should reflect this

• The environment tells us it supports 24-bit color

  • Jinxed could/should support this
  • Does this mean it returns a *-direct variant or patches what it returns?

• color support is determined by XTGETTCAP

  • Blessed will do this discovery
  • What mechanism would Blessed use to pass this to Jinxed? Does Blessed pass info to Jinxed to overlay? Or does it pass a parameter to jinxed.Terminal so jinxed pulls the *-direct variant? Or does it do something like Termninal.force_color() as a shortcut to the overlay? Or does it just ask for the *-direct varient?

• 24-bit support can't be determined

  • Jinxed should default to the lowest common denominator
  • Blessed or the user should support forcing it

[jquast]

I was thinking of minimizing jinxed detection to only a unique $TERM type defines color = 1 << 24.

But it really is very little change, probably better all done in blessed.

The idea that TERM=contour, kitty, rio, etc., also indicates 24-bit color support. I can just move this issue there entirely, jquast/blessed#386