From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: About the :distant-foreground face attribute Date: Mon, 13 Jan 2014 13:36:51 -0800 Message-ID: <52D45C73.6090906@dancol.org> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1389649022 1876 80.91.229.3 (13 Jan 2014 21:37:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Jan 2014 21:37:02 +0000 (UTC) Cc: Eli Zaretskii , Chong Yidong , emacs-devel To: =?ISO-8859-1?Q?Jan_Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 13 22:37:09 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 1W2pC1-0003Az-6G for ged-emacs-devel@m.gmane.org; Mon, 13 Jan 2014 22:37:09 +0100 Original-Received: from localhost ([::1]:45143 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2pC0-00063w-QI for ged-emacs-devel@m.gmane.org; Mon, 13 Jan 2014 16:37:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2pBx-00063r-A9 for emacs-devel@gnu.org; Mon, 13 Jan 2014 16:37:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2pBw-0008CE-79 for emacs-devel@gnu.org; Mon, 13 Jan 2014 16:37:05 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:54381) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2pBs-0008Ba-Vw; Mon, 13 Jan 2014 16:37:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=r3muwe1uPFERF7TeOl6PI8eQpQbvkwgUnjzFUoAjMD8=; b=hNPpUZLO4fxgVC2/Hftbe+oYa9QBVkr43WShmfgLAOHI8NYg49Jq/iarX1srvPAlk7iQVWE5QDEX14/SRnB26J6QWR2isBXncjMykuwEMzDHPPAeX77QWl0QmbBNWdB7AeHs73VDvKCw+QUcGlwNhlx373qTYdSyCZx+FtyFre4pkknSMSNzjexNofOqKTrrruTBZe3oyEmfIKa7BDBXxVe9KGhlNBOJWM7sdm9IWZ4zADVyocS7CkD7cQJU+0pOfGu9YwCIHxMS4dwTDZUXimHckHD86nwdGi2WGqSHP+A2v1mjcQSojQuEvM3i+8hXYoeGFdjmlgeW2+PnA6qbug==; Original-Received: from [2620:0:1cfe:a0:863a:4bff:fec8:e538] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W2pBr-0000jS-D8; Mon, 13 Jan 2014 13:36:59 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <9BD01B88-AF13-44DD-8DBE-4598BAC136DD@swipnet.se> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:168317 Archived-At: On 01/13/2014 01:29 PM, Jan Djärv wrote: > 13 jan 2014 kl. 19:41 skrev Daniel Colascione : > >> On 01/13/2014 08:33 AM, Jan Djärv wrote: >>> 13 jan 2014 kl. 14:13 skrev Daniel Colascione : >>>> The patch uses the CIE L*A*B colorspace algorithm by default. >>> >>> Do not change the defaults please. Reinstate the >>> *_selection_fg_color. >>> They are system defined and should be honored. >> >> There are two sane defaults: the 24.3 behavior, where we always use the system selection foreground and background, and my proposed behavior, where we use the fontified foreground and automatically adjust it so that it's legible. The current behavior is worse because it uses the system selection foreground only sometimes and doesn't preserve theme hues when possible. > > What theme hues? The default theme is not really a theme as > selection colors are taken from system settings. And this is correct IMHO, any application that doesn't do so by default (i.e. no user configuration has been set in the application) is seriously broken. Yes, but font-lock colors are specified with explicit colors (even in the default "theme"), and we want to preserve these even in the presence of a selection. We are *already* not honoring the system-specified foreground selection color. At the same time, we want to make sure that highlighted text is legible against a background of whatever the system selection color happens to be. The best way to do that is to automatically shift the foreground colors in value, but not hue, so that they remain legible while being recognizably the same color. I think the results are actually pretty good. If a particular theme doesn't want to use automatic color adjustment, it can specify its own :contrast-function and do whatever it wants. I would also support a scheme where, by default, 'region' sets foreground *and* background colors to the system selection colors and other faces don't show through. But we didn't decide to go in that direction. > If you talk about other themes, they can set :distant-foreground to > a real color of their choosing and not rely on some automatically generated one which most probably don't fit the theme anyway. Automatically generated colors are a crutch which should be avoided if possible, certainly not recommended. There's no way that themes can take into account all the possible colors users and packages might use. Automatic contrast adjustment can do that. If you want the :distant-foreground behavior, it can be accommodated in this patch. This patch also permits other schemes that some users might find more useful. We should push policy to user customization when possible instead of hardcoding policy in the logic of face attributes.