options: Add truecolor to control the mode

[JoeKar]

Currently even 256 color schemes like the default one don't look as defined and then most probably expected due to used terminal palette. So I suggest to determine the true color support based on the already mentioned $COLORTERM environment variable and furthermore the overall control should be able with a micro internal option to prevent the additional definition of a further user defined environment variable.

w/o vs w/ true color support/mode:

This could close #2859 too.

[dmaluka]

Why not make auto the default?

And if make it the default, then also need to let the user override auto by setting MICRO_TRUECOLOR=1, for cases when the terminal supports truecolor but does not set COLORTERM (there are such terminals out there). But looks like your code is already doing that, although the above description does not mention it, it only mentions that MICRO_TRUECOLOR=1 overrides off.

BTW also maybe it's better to let MICRO_TRUECOLOR override auto only, not let it override off, i.e. maybe truecolor=off should have higher priority than MICRO_TRUECOLOR=1? (Or perhaps it's not so important which of the two has higher priority...)

[dmaluka]

also need to let the user override auto by setting MICRO_TRUECOLOR=1

On second thought, the user could as well override it by setting truecolor to on. And generally, looks like the MICRO_TRUECOLOR env var becomes superfluous once we have the truecolor option. But if we do need to keep supporting MICRO_TRUECOLOR for backward compatibility, then we should keep its behavior consistent.

[JoeKar]

Why not make auto the default?

This would directly mean changing the "expected"/known behavior, because it's documented till now with...

"True color support in micro is off by default [...]"

Furthermore it's common to have the user-defined terminal color palette applied to the editor/application. So from that perspective I thought about this as well, but came to the conclusion that the change would be to drastic.

And generally, looks like the MICRO_TRUECOLOR env var becomes superfluous once we have the truecolor option.

Yes, definitely. With the introduction of the options the control via additional env vars should have been removed to have a single point of truth. If @zyedidia (as project owner) endorses the removal of the env var, then I'm fully for the removal of it too and set the option default to auto or off.
The only strange setting would be to have $MICRO_TRUECOLOR=0and truecolor=auto|on. From my perspective the activation will override the disabled env var...so I documented this now explicitly.

[dmaluka]

This would directly mean changing the "expected"/known behavior, because it's documented till now

Yes, but it doesn't necessarily mean that it is the most desired behavior. And weren't you the one advocating for making autodetection work out of the box (in #2859 (comment))?

In particular, regarding:

Furthermore it's common to have the user-defined terminal color palette applied to the editor/application.

It is common for 16-color palettes, but I'm not sure how common it is for 256-color palettes. And anyway, I'd assume that if a user wants to use his custom terminal colors in micro, he'd rather prefer using a 16-color or 256-color colorscheme accordingly, not a truecolor colorscheme (which probably wasn't designed to look as good in custom colors as in true colors), so that truecolor settings wouldn't affect him.

Anyway... as I've discovered that the tcell library actually enables truecolor by default if available (as I've noted in my other comment above), and micro deliberately disables it by default by setting TCELL_TRUECOLOR=disable, looks like it is actually an intended behavior. But I don't quite understand what is the reason for doing so.

@zyedidia could you please clarify:

1. What was the reason for overriding tcell's default behavior (enable truecolor, if available) with micro's behavior: disable truecolor, unless MICRO_TRUECOLOR=1 is set?
2. Some of the colorschemes that are mentioned in help colors as 256-color schemes (including the default colorscheme) are actually specified in their colorscheme files with RGB values, not with 256-color codes (and as a result, they are affected by truecolor being enabled or not). What was the reason for that?

[JoeKar]

Yes, but it doesn't necessarily mean that it is the most desired behavior.

Yep, I'd like to have it on by default too, but it isn't my decision and the only intention was to not change the default behavior.

And weren't you the one advocating for making autodetection work out of the box (in #2859 (comment))?

Yes, I was and I still be. As you found out it's already done by tcell and this is fine.

[Neko-Box-Coder]

The only strange setting would be to have $MICRO_TRUECOLOR=0 and truecolor=auto|on. From my perspective the activation will override the disabled env var...so I documented this now explicitly.

@JoeKar

I think we should respect $MICRO_TRUECOLOR first and truecolor second, so that this allows us to make truecolor to be auto|on by default.

Not the other way around where we default truecolor to off and have to figure out a way to make it to on by default in the future.

Then we can mark $MICRO_TRUECOLOR to be legacy / deprecated and transition to remove it at some point.

Any chance that we can merge this PR at some point?

[JoeKar]

Dmytro summarized it really good with his #2867 (comment).
The confusing aspect is the different default behaviors between tcell and micro. In general it's off by design of micro while using a default color scheme which has a different look between the modes.
Changing the default behavior again means breaking with compatibility/expectation.

[Neko-Box-Coder]

@JoeKar
Assuming we respect $MICRO_TRUECOLOR first but have truecolor to be auto|on

The only group of people I can think of that will be affected by this change is

• People who don't have $MICRO_TRUECOLOR set to 1 and use a truecolor color scheme

which is a wrong behavior and they are probably not getting what they think they are getting anyway.

But unfortunately, this also affects the default color scheme. We can either:

• Convert it to 16 palette which would affect the people that is using it as true color
• Leave it as it is which would affect the people that is using it as (16 or ) 256 palette color

I am leaning toward the second option but either way seem fine to me,

Right, and we also need to correct the color schemes we have to match the title (or the other way around, idk)
Assuming color schemes with tc suffix are true color and ones with 16 suffix are 16 palette and ones with no suffix are 256 palette.

Here are all the ones that the name do not match the color depth:

• atom-dark.micro
  • Should have tc suffix
• darcula.micro
  • Should have tc suffix
• default.micro
  • This is using monokai, which is using truecolor
• geany.micro
  • Should have 16 suffix
• gotham.micro
  • Should have tc suffix
• monokai-dark.micro
  • Should have tc suffix
• monokai.micro
  • Should have tc suffix
• one-dark.micro
  • Should have tc suffix
• railscast.micro
  • Should have tc suffix
• simple.micro
  • Should have 16 suffix
• solarized.micro
  • Should have 16 suffix
• twilight.micro
  • Should have tc suffix

Changing the name would be the easiest, but would also break people's config. We can probably do something like search for tc and 16 suffix if the one in config can't be found, and then use that (and also give a warning to tell the user to correct the color scheme name)

I think either way this is going to be breaking compatibility anyway at some point (unless we never switch to truecolor as default), we might as well do it now.

[dmaluka]

This would directly mean changing the "expected"/known behavior, because it's documented till now

Yes, but it doesn't necessarily mean that it is the most desired behavior. And weren't you the one advocating for making autodetection work out of the box (in #2859 (comment))?

In particular, regarding:

Furthermore it's common to have the user-defined terminal color palette applied to the editor/application.

It is common for 16-color palettes, but I'm not sure how common it is for 256-color palettes. And anyway, I'd assume that if a user wants to use his custom terminal colors in micro, he'd rather prefer using a 16-color or 256-color colorscheme accordingly, not a truecolor colorscheme (which probably wasn't designed to look as good in custom colors as in true colors), so that truecolor settings wouldn't affect him.

Anyway... as I've discovered that the tcell library actually enables truecolor by default if available (as I've noted in my other comment above), and micro deliberately disables it by default by setting TCELL_TRUECOLOR=disable, looks like it is actually an intended behavior. But I don't quite understand what is the reason for doing so.

@zyedidia could you please clarify:

1. What was the reason for overriding tcell's default behavior (enable truecolor, if available) with micro's behavior: disable truecolor, unless MICRO_TRUECOLOR=1 is set?
2. Some of the colorschemes that are mentioned in help colors as 256-color schemes (including the default colorscheme) are actually specified in their colorscheme files with RGB values, not with 256-color codes (and as a result, they are affected by truecolor being enabled or not). What was the reason for that?