Colorschemes broken! Color diverges since 2.0.15!

[zDEFz]

Description

Blue: Colorscheme https://pastebin.com/KxHYm2t1

Using alacritty. Tried couple versions, no change, only downgrading micro to 2.0.14 from 2.0.15 helped.
Using default alacritty config doesn't fix it either.

How it looked before:

How it looks now:

What happened there?

Environment

• Version: 2.0.15
• OS: archlinux
• Terminal: alacritty

[Neko-Box-Coder]

Could you check if micro has enabled true color or not, if it makes any difference?

See
https://github.com/micro-editor/micro/blob/master/runtime/help/colors.md#true-color

[zDEFz]

Could you check if micro has enabled true color or not, if it makes any difference?

See https://github.com/micro-editor/micro/blob/master/runtime/help/colors.md#true-color

No improvement at all.

[Andriamanitra]

The new version is using the colors as you specified them as true color is now the default behavior. The old one is using an approximation (for example the background is #005F87 instead of #4B6881). If you set truecolor off you should get the old (less accurate) colors back, but you probably want to modify the color scheme to specify the actual colors you want rather than ones that get "rounded" to the "right" colors.

This was changed in #2867, you may read the PR discussion and the linked issue for more context.

[zDEFz]

The new version is using the colors as you specified them as true color is now the default behavior. The old one is using an approximation (for example the background is #005F87 instead of #4B6881). If you set truecolor off you should get the old (less accurate) colors back, but you probably want to modify the color scheme to specify the actual colors you want rather than ones that get "rounded" to the "right" colors.

This was changed in #2867, you may read the PR discussion and the linked issue for more context.

set truecolor off has absolutely no effect for me when used as command in micro.
But when using settings.json, "truecolor": "off" gives us the expected result after relaunching micro
Perhaps that's a bug. I entered it in the command section in micro >

I will try to get 'the correct' colors with changes in my colorscheme now.

[Andriamanitra]

set truecolor off has absolutely no effect for me when used as command in micro. But when using settings.json, "truecolor": "off" gives us the expected result after relaunching micro Perhaps that's a bug. I entered it in the command section in micro >

It's not a bug, I just forgot to mention that changes to truecolor will only take effect on the next restart (this is documented in help options).

[zDEFz]

set truecolor off has absolutely no effect for me when used as command in micro. But when using settings.json, "truecolor": "off" gives us the expected result after relaunching micro Perhaps that's a bug. I entered it in the command section in micro >

It's not a bug, I just forgot to mention that changes to truecolor will only take effect on the next restart (this is documented in help options).

One thing left: When I created my colorscheme, I found that the namings were really confusing of what does what.
Is there a better overview, maybe even a picture that visualizes it?
I do my edits without any idea what is what, even though I had commented it.
It is very frustrating.

[JoeKar]

You are talking about an probably insufficient color-scheme documentation?

[Andriamanitra]

One thing left: When I created my colorscheme, I found that the namings were really confusing of what does what.
Is there a better overview, maybe even a picture that visualizes it?

A web app that allows you to browse and edit colorschemes with a real time preview (and clear labels for what color-link affects what) would be useful. I've seen ones for VSCode ¹ and vim ² but I'm not aware of any that supports micro's colorschemes. I built a little demo as a proof of concept but I don't think I'll keep working on it further, feel free to steal the code and/or the idea: https://codepen.io/Andriamanitra/pen/azZKELj

Footnotes

1. https://themes.vscode.one/ ↩

2. https://bytefluent.com/vivify/ ↩

[zDEFz]

https://codepen.io/Andriamanitra/pen/azZKELj

Thank you a lot!

You are talking about an probably insufficient color-scheme documentation?

As the demo demonstrated, there are a lot of options one can use.
This is not about sufficiency, it's about ease of use, which I don't see given for a casual user.

Updating and seeing colors differently - it would been nicer if there was a warning displayed and guidance given.

When we need to make a colorscheme, we should immediately see cause and effect.

The tool posted by @Andriamanitra standardizes this a bit more.
Looking into footnotes:
Vivify goes a step further and includes (click on line number) to change color of line number type of feedback, which is quite nice.

It is about reducing friction.
I will see if I can continue the tool shown in codepen.
Best would be completely interactive.

[JoeKar]

This is not about sufficiency, it's about ease of use, which I don't see given for a casual user.

Does the "casual user" create new colorschemes?

Updating and seeing colors differently - it would been nicer if there was a warning displayed and guidance given.

This means, that the previously used/created color scheme defined colors out of the 16 or 256 color range and due to inactive truecolor mode they have been approximated...

colors.md#creating-a-colorscheme:

Color terminals usually have 16 colors that are preset by the user. [...] You can use those colors with the names black, red, green, yellow, blue, magenta, cyan, white and the bright variants of each one (brightblack, brightred...).
[...]
If the user's terminal supports true color, then you can also specify colors exactly using their hex codes. If the terminal is not true color but micro is told to use a true color colorscheme it will attempt to map the colors to the available 256 colors.

Unfortunately micro forcefully disabled truecolor in the past by default while using a trucolor colorscheme as default.
Others complained about the fact that truecolor isn't used by default.

Anyway, the initial issue seems to be solved and improving the documentation resp. creation of a demonstration is more a new feature than bug. Maybe the community can support here to improve this situation. 😉