Re: [PATCH] Re: About the :distant-foreground face attribute

["Jan D." <jan.h.d@swipnet.se>]

Hello.

Yuri Khan skrev 2014-01-15 05:50:

>
> We have region highlighting. We have Isearch highlighting the current
> match and all other matches. We have hl-line and
> highlight-current-line. We have an option in whitespace-mode and a
> highlight-beyond-fill-column mode to highlight things that exceed a
> preconfigured line length.
>
> We have ediff highlighting deleted text, inserted text, merged text,
> word-refined deleted/inserted/merged text, active difference, even and
> odd other differences. We have MuMaMo-like modes highlighting runs of
> code in a different programming or markup language.
>
> In all of these cases, I as a user would like (1) syntax highlighting
> (font-lock) to be retained and visible through the highlight; (2) all
> resulting color combinations to be of suitable contrast and proper
> brightness relationship; (3) all that without a combinatorial
> explosion of having to define a separate pair of colors for each
> combination of a font-lock face with a highlight face.
>
>
> Importantly, the word “suitable” in the above sentence does not always
> mean “suitably high”. I use global-whitespace-mode to visualize
> spaces, line breaks and tabs. For these, I configure a low-contrast
> foreground. I want them to stay low-contrast *and* still visible, no
> matter which highlight is overlaid.
>
> As an example: My default background is aluminium6 (#f7f8f5, hereafter
> all colors are from the extended Tango palette[1]). My region color is
> skyblue5 (#97c4f0). I use hl-line with background of aluminium5
> (#ecf0eb). I have to choose a foreground color for the whitespace
> marks so that it is sufficiently low contrast on all these backgrounds
> as not to distract from the main text; and that it is visible on and
> darker than each of these backgrounds.
>
> For display on the default background, aluminium4 (#d3d7cf) would be
> about right. But if I choose that, whitespace markers become lighter
> than the region background, which is visually unpleasant. So I’m
> forced to take the darker shade, aluminium3 (#babdb6), even though it
> is now a bit too visible on the default background.
>
> [1]: http://emilis.info/other/extended_tango/
>
>
> Thinking about it, I feel I might appreciate a system that would not
> use fixed absolute foreground colors but blends instead. E.g. in my
> light background setting, region would multiply both the background
> and the foreground by #9ccafa. This would turn the default
> black-on-aluminium6 into black-on-skyblue5 while turning the
> whitespace marks from aluminium4 into just a bit lighter than
> skyblue4. Similarly, hl-line would multiply the colors by #f4f7f5.
>
> (The multiplicative model is only good for light backgrounds. Dark
> backgrounds would need some other combination formula, possibly
> something similar to (1-(1-x)*(1-y)). Alpha blending might seem more
> general, but yields lower overall contrast. I also don’t have a
> solution for fixed-palette 8-, 16-, 88- and 256-color displays.)
>

As you note, the lack of contrast is a general problem for all cases
when more than one face can be applied.  But no user has been
sufficiently annoyed to file a bug report except for the selection
case, so it has been an ignored/unknown problem.  In hindsight, I kind
of regret trying to fix this and thus put focus on the issue.
I should have done as has been done in the past, just ignore the whole
issue.

	Jan D.