From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Yuri Khan Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: About the :distant-foreground face attribute Date: Wed, 15 Jan 2014 11:50:31 +0700 Message-ID: References: <87bnzo9cja.fsf@gnu.org> <59B7E7FC-48D0-4737-B1BB-FFAC5BA9E07A@swipnet.se> <874n5f3162.fsf@gnu.org> <83fvozf86g.fsf@gnu.org> <87r48javwe.fsf@gnu.org> <83bnzmfjxe.fsf@gnu.org> <52D3E689.6050902@dancol.org> <8E16225F-53EF-498A-AB35-66EB9B33B859@swipnet.se> <52D43360.6050605@dancol.org> <9BD01B88-AF13-44DD-8DBE-4598BAC136DD@swipnet.se> <52D45C73.6090906@dancol.org> <52D47289.2020700@dancol.org> <52D4A23E.4030802@dancol.org> <2798eddb-c6c7-4b73-8bd0-e4bd72f3405e@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389761436 13852 80.91.229.3 (15 Jan 2014 04:50:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2014 04:50:36 +0000 (UTC) Cc: Eli Zaretskii , Daniel Colascione , Chong Yidong , =?UTF-8?Q?Jan_Dj=C3=A4rv?= , emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 15 05:50:44 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W3IR9-0000mf-GM for ged-emacs-devel@m.gmane.org; Wed, 15 Jan 2014 05:50:43 +0100 Original-Received: from localhost ([::1]:52078 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3IR9-0005Mh-5Y for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 23:50:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44319) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3IR5-0005M8-Ph for emacs-devel@gnu.org; Tue, 14 Jan 2014 23:50:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3IR2-0007O8-Qo for emacs-devel@gnu.org; Tue, 14 Jan 2014 23:50:39 -0500 Original-Received: from mail-qc0-x22c.google.com ([2607:f8b0:400d:c01::22c]:48346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3IQy-0007Mk-MK; Tue, 14 Jan 2014 23:50:32 -0500 Original-Received: by mail-qc0-f172.google.com with SMTP id c9so564111qcz.31 for ; Tue, 14 Jan 2014 20:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=lCISKNSflGVkQrzrVJgZv5hsJiG5WXDI0EN9aLNjwjs=; b=bnFn0jE9js3v5TydZbJnux0g/hX+5aOlv9oJmTbYJVNZ2rvVYVz5OLRNTbk9jlBNga a2K5eI+sLSLbx8rzfVF+5y3uwixc+qLqId/XoYWy+AD5zZjBtSXo4V81ruKjc5TAAenO AfBsJzgivpvKRP8LFLfquY/uHwOEjVbHp+mWMF1TBp0+2s2661sK9r+AA9SWCAjSBYZO 54xVL4PgKmSl+UqupxJ95hlKY+Uh2VwSFvSh92glUBj7cOGQRqt4U5U6m0Mq9EluvrLW xmpp745KsvzGYM2liZ9dZpZEj114dnH8OeNjJPExWC4CTbi+XZU6oedbuhsD3ep4TGiW CLzw== X-Received: by 10.49.49.199 with SMTP id w7mr202057qen.52.1389761431942; Tue, 14 Jan 2014 20:50:31 -0800 (PST) Original-Received: by 10.96.14.74 with HTTP; Tue, 14 Jan 2014 20:50:31 -0800 (PST) In-Reply-To: <2798eddb-c6c7-4b73-8bd0-e4bd72f3405e@default> X-Google-Sender-Auth: jRtO-f7LLCqg2XA2ZGr68JYYqFM X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c01::22c X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:168427 Archived-At: On Wed, Jan 15, 2014 at 2:32 AM, Drew Adams 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 =E2=80=9Csuitable=E2=80=9D in the above sentence does= not always mean =E2=80=9Csuitably high=E2=80=9D. I use global-whitespace-mode to visua= lize 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=E2=80=99m 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=E2=80=99t have a solution for fixed-palette 8-, 16-, 88- and 256-color displays.)