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 00:18:10 -0800 Message-ID: <52D4F2C2.8080800@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> 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 1389687511 29418 80.91.229.3 (14 Jan 2014 08:18:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 08:18:31 +0000 (UTC) Cc: Eli Zaretskii , Chong Yidong , emacs-devel To: "Jan D." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 14 09:18:37 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 1W2zCi-0006lb-56 for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 09:18:32 +0100 Original-Received: from localhost ([::1]:47012 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2zCh-00040I-MV for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 03:18:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49839) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2zCd-00040B-Ub for emacs-devel@gnu.org; Tue, 14 Jan 2014 03:18:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2zCc-0003aq-Eo for emacs-devel@gnu.org; Tue, 14 Jan 2014 03:18:27 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:56054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2zCW-0003Xy-6c; Tue, 14 Jan 2014 03:18:20 -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=oRm9BqsJlIuq/Qg8L7M9oMUpzBHRrV89CbQl9r4lgmk=; b=PC1x8K2fehdba2Fz3SKOCTKeuoeT5Rm6h431++64Bp4/0nac953o4bXIuUocnMc+q1d/3sC9hLXhuI5tNSKf7B5r6QDM3cfnlB8pUstVmG79/zQXL1bmgcJPCPVGAGt5cqG8wgjpsNPFtTw6jalATKp1rtnmICSgHoMOC0GBX/BAAblFlH0K57PBUDcnDNlp/B/g0lAjVfcDj8Akzus0q2oldpzwU4m4hufSg9/5Utcmd0p1QXSeQtNfHJFVZs3Ut2g3i6jA2lCtAK+IvRNnQ2LCB5kP/OvhIUAYW7ZCVuLAyQq6Bd+rodJqrB6EhAWQWFXxWMLqLrBUpsP1yuHo0Q==; 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 1W2zCV-0001h8-28; Tue, 14 Jan 2014 00:18:19 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <52D4EBA9.8050802@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:168341 Archived-At: On 01/13/2014 11:47 PM, Jan D. wrote: > Your mailer does not quote replies properly, which is distracting. Can > you fix that? It looks fine to me. > Daniel Colascione skrev 2014-01-13 22:36: >> 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. > > 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. >> 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. > > FWIW, here Eclipse, XCode and Visual Studio all shows the (equivalent > of) foreground color from font lock face and background from region when > selecting text with the mouse, so it is not as Eamcs is breaking new > ground here. > >> >>> 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. > > Again, I really don't see this use case. Do you have one? I just mentioned one. See my other email, the one where I laid out the options for Emacs configuration defaults. >> We should push policy to user customization when >> possible instead of hardcoding policy in the logic of face attributes. > > I don't think we do that, users can still customize faces as they see fit. :distant-foreground has far too narrow a justification to warrant being a face property by itself.