Add basic dimming functionality

[farwyler]

This adds a first iteration of color dimming to the editor.

You can:

1. Dim the colors of all unfocused views
2. Dim the colors in the background of Overlays (pickers, etc.)

The following dimming functions are implemented:

• "dim" just set the modifier flag "dim" of all cells
• "lighten" / "darken" actually change the shade of the fg/bg colors. this only works for themes applying RGB colors, not ANSI colors.

Config example:

[editor.dim] Section

Enable dimming in certain areas. Disabled by default. Enable by assigning:

• 0 = set text modifier flag DIM
• negative value = darken colors (-127 = 100% darker)
• positive value = lighten colors (+127 = 100% lighter)

darken/lighten colors only works with themes that set rgb colors, not indexed colors.

Key	Description	Default
overlay-backdrops	Enable dimming and set shade of content behind overlays.	None
unfocused-views	Enable dimming and set shade of unfocused editor views.	None

[editor.dim]
# darken backdrop of overlays
overlay-backdrops = -25
# dim fg color of unfocused views
unfocused-views = 0

Screenshots:

Todo:

• feedback
• documentation
• some optimizations

Looking for feedback.
Do we actually want this functionality in the tui?
Leave this to alternative frontends or plugins later?
Could this be used with #1187 ?

[sudormrfbin]

I guess this is a nice to have, but a config for it seems overkill, especially the kind of dimming functions to use. If this does get merged, we would also want to avoid pulling in a dependency (palette) simply to dim colors.

---

It does feel like a good usability improvement after trying it out though, so I'm more or less on the fence now 😛

[CptPotato]

I guess this is a nice to have, but a config for it seems overkill, especially the kind of dimming functions to use.

If I'm reading the palette source correctly, darken(x) is just lighten(-x) so the config could probably be simplified. Even if the palette crate isn't used the option could still be represented as a single value.

[farwyler]

thanks @CptPotato and @sudormrfbin for the feedback.
i have simplified the implementation and removed the dependency.
new configuration looks like this.

[archseer]

Doing dimming across an entire area after the fact seems a bit of a hack -- I'd rather calculate the dimming inside render_view, similar to how we treat active/unfocused views by passing a bool into that function.

[farwyler]

@archseer You are right, the post processing is quite hacky. I wanted to keep the dimming out of the rendering functions if possible, as it introduces code complexity there for something that is a graphical gimmick, at best a slight UX improvement.

With bb4fec7 i've tried another an implementation that does the dimming ad-hoc, with just slight adjustments to the main render loop and a little state in the drawing buffer.

[pascalkuthe]

clsoing this one as stale. Almost the entire rendering code has been removed since so this would need to start over from scratch. Thank you for contributing!