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: Tue, 14 Jan 2014 12:06:07 -0800 Message-ID: <52D598AF.9050306@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> <52D45C73.6090906@dancol.org> <52D4EBA9.8050802@swipnet.se> <52D4F2C2.8080800@dancol.org> <52D504A7.80104@swipnet.se> <52D514FF.7010404@dancol.org> <52D52312.6070106@swipnet.se> <52D58632.3010106@dancol.org> <381DEBDC-71D8-4FAC-BA55-897FEC73A2FC@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 1389731982 17525 80.91.229.3 (14 Jan 2014 20:39:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 20:39:42 +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 Tue Jan 14 21:39:50 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 1W3Am5-0006tJ-Ch for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 21:39:49 +0100 Original-Received: from localhost ([::1]:50572 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3Am5-00032Y-17 for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 15:39:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42502) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3Alj-0002Vk-2B for emacs-devel@gnu.org; Tue, 14 Jan 2014 15:39:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3Alh-0000SP-RE for emacs-devel@gnu.org; Tue, 14 Jan 2014 15:39:26 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:57965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3Ale-0000Rd-UQ; Tue, 14 Jan 2014 15:39:23 -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=7OJK2lqy1+sTiEpUasRz+FmxXgX4tRkjG03ONCfKUcc=; b=XYoUxVm0oW+dd0oC6LruhRaLZa7Jz6cgaLeeIrATZpaslu5F2ejJskVF9MWwX+9VJt3+gaLBCWarAnkZYPjcW+529EgRfKtqz2UGer5YRp1Ot+oropwJj0MdOtLiC1QPO6IIZgeW2bRPD7mxrsA9omjALbLULOesvTQ7wNcXvBPXxxKLIAP+2J+ido1LSm8JvCFF2A7ND9J6BHH95IjWMy0Qb47cg9ofWWTN9zsqOsBHFwKs6OG3vmie8QfbHKcdUT+UDMzMlyEdyBaOXChRIgHp6PpMTwyNzXlmxJqCJ9UNJ8u8Tqnshu1hk3mUONiLYfWqrJnJuRB2EvZZZB3MQQ==; Original-Received: from [2601:8:b200:217:863a:4bff:fec8:e538] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W3AFZ-0002m7-7i; Tue, 14 Jan 2014 12:06:13 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <381DEBDC-71D8-4FAC-BA55-897FEC73A2FC@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:168393 Archived-At: On 01/14/2014 12:01 PM, Jan Djärv wrote: > 14 jan 2014 kl. 19:47 skrev Daniel Colascione : > >> On 01/14/2014 03:44 AM, Jan D. wrote: >>> Daniel Colascione skrev 2014-01-14 11:44: >>>> On 01/14/2014 01:34 AM, Jan D. wrote: >>>>>>> Given the use case at hand, we know for a fact that the background is >>>>>>> the region background, so I don't understand why a calculated >>>>>>> foreground >>>>>>> is needed. Just pick one that matches the background. >>>>>>> There might be other use cases where a calculated foreground makes >>>>>>> sense, but my imagination fails me here. >>>>>> >>>>>> Calculated foreground colors look better: they resemble the font-lock >>>>>> colors on which they're based. >>>>> >>>>> For the region case, that would imply the possibility of different >>>>> foregrounds for marked text, none which is the actual font-lock color. >>>> >>>> It *is* the same color in the sense that the code we generate has the >>>> same hue. How on earth is that worse than changing arbitrary font-locked >>>> pieces of text to the system selection foreground color? >>> >>> Because the system color foreground is (presumably) choosen to look good >>> together with the system color background. >> >> Yes, and a color we algorithmically generate from a font-lock face will *also* look good against that background color, but 1) will be distinct from other faces replaced for lack of contrast, and 2) will be visually similar to the pre-highlight face. Have you tried the patch? > > No. If Emacs generates a color, Emacs desides what looks good. If > the system defines a color, the system (or the user if customized) > desides what looks good. I don't think it matters what I think about > colors generated by your patch, I might even think they look better > than many system defined colors. But as a principle I think the > desision is not Emacs to make *by default*. Users may of course > apply customizations to Emacs and change it. In 24.4, Emacs has already been changed to override the system selection foreground color with various font-lock faces. Why is it okay to do that when there's no contrast problem, but suddenly, when there's a contrast problem, we can say that the principle of following system colors is important? You're applying this principle very selectively. If you're going to override the system color selection, you need to do it well and consistently, and automatic contrast adjustment is the best way to go about solving the inevitable contrast problems that arise when you combine colors you control with colors you don't.