[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan D.
Subject: Re: [PATCH] Re: About the :distant-foreground face attribute
Date: Wed, 15 Jan 2014 08:50:03 +0100
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130328 Thunderbird/17.0.5


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

        Jan D.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]