[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: Yuri Khan
Subject: Re: [PATCH] Re: About the :distant-foreground face attribute
Date: Wed, 15 Jan 2014 11:50:31 +0700

On Wed, Jan 15, 2014 at 2:32 AM, Drew Adams <address@hidden> wrote:
> And note that the "problem", of text highlighted by the selection
> (region) having foreground and background the same, is the same
> problem you will anyway encounter for Isearch.  In your example,
> even when searching you can run into the same problem.
> Will you be proposing that Isearch highlighting too let font-lock
> highlighting show through?

The problem is in fact deeper than that.

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.)

reply via email to

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