For context, the full meaning of the current Linux color command line option values is:
8: 8 background colors and 16 foreground colors.
16: 16 background colors and 16 foreground colors.
rgb: 16,777,216 background colors and 16,777,216 foreground colors.
That actual meaning needs to be simplified, and I think the current solution is a good one.
As for Sammy’s proposed editor variable values _8_ and _16_, I suggest simply using 8 and 16.
I suggest _rgb_ to stand for 1, because if I recall correctly editor integer variables cannot be larger than 65536, and because this avoids referencing a meaning that is different from the other values’ meaning.
We do not have to anticipate larger numbers of colors, because those would break TSE’s current architecture.
Based on Guy’s feedback I propose an even simpler name: “colors”.
And definitely for the command line option and the editor variable to get the same name!
To view this discussion on the web visit https://groups.google.com/d/msgid/semware/em09160d20-d7d8-427e-8891-90e6e0c2437a%4054701274.com.
For your consideration,
I have pre-started on making some of my Windows GUI extensions Linux compatible, namely some of those that are dependent on RGB color support.
I created a mock function rgb_support() to test backwards-compatibly whether the user’s TSE variant and version supports RGB colors.
From this mock function I learned two things that are of interest for implementing the next Linux TSE release:
Obviously TSE’s INTERNAL_VERSION directive needs to be incremented.
The editor variable "Colors" (or what its name actually will be) also needs to have value _RGB_ when the command line option "-colors rgb" was used.
integer proc rgb_support()
integer result = FALSE
#if INTERNAL_VERSION >= 12373
if Query('Colors') == _rgb_
result = TRUE
result = TRUE
Warn('RGB support:'; iif(rgb_support(), 'Yes', 'No.'))