From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [PATCH] Re: About the :distant-foreground face attribute Date: Tue, 14 Jan 2014 16:31:45 -0800 (PST) Message-ID: <432c1d5b-0b1e-4bf9-83ec-551d16f1f515@default> 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> <52D5BC79.7050706@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389745944 20488 80.91.229.3 (15 Jan 2014 00:32:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2014 00:32:24 +0000 (UTC) Cc: Eli Zaretskii , Chong Yidong , emacs-devel To: Daniel Colascione , =?iso-8859-1?B?SmFuIERq5HJ2?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 15 01:32:30 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 1W3EPF-0000Of-7B for ged-emacs-devel@m.gmane.org; Wed, 15 Jan 2014 01:32:29 +0100 Original-Received: from localhost ([::1]:51359 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3EPE-0003f9-Jx for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 19:32:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35994) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3EP3-0003en-QO for emacs-devel@gnu.org; Tue, 14 Jan 2014 19:32:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3EOv-0000RZ-6y for emacs-devel@gnu.org; Tue, 14 Jan 2014 19:32:17 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:25805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3EOl-0000R4-Ty; Tue, 14 Jan 2014 19:32:00 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0F0Vo4A026347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Jan 2014 00:31:51 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0F0VkrR008870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jan 2014 00:31:47 GMT Original-Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s0F0Vk6t019208; Wed, 15 Jan 2014 00:31:46 GMT In-Reply-To: <52D5BC79.7050706@dancol.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:168408 Archived-At: > >> If a user never expressed a preference with respect to foreground > >> and background colors, there's no contract to violate. > > > > And how does she express that preference, if it happens to > > coincide with the default colors? >=20 > See above. So she has to opt out. She has to realize that she really wants the default color attribute values, which she never really sees because the automatic tweaking is on by default. And then she has to explicitly opt out, to get those colors she has finally realized she wants. Just turn it off by default. For those few platforms that are ill-designed enough to present a problem, she will figure out whether she wants to remedy that problem by opting into the automatic twiddling. If there really is a visible problem on her platform then she will see it and will be able to make an informed choice. Call out this clever compensation in the doc. > > What you are saying is like saying that you think you have a > > license to change the value of option `default-frame-alist' > > automatically, if the current value is nil, because that's also > > the default value. >=20 > Well, yes, we do have such a license. By this logic, we can't change > any default ever. Did you notice "automatically" and "current value" in that sentence? I'm not talking about the license of Emacs Dev to redefine the _default_ value. I'm talking about license to change the _current_ value of an option, on the fly, automatically, behind the user's back... - just because the current value happens to coincide with the default value (`nil' in this case). A user's not customizing an option away from the default value is not implicit permission for Emacs to twiddle the current value to something different. > >>> But it still makes life more complicated for Lisp code that > >>> wants to get or set the actual appearance of the face. Whereas > >>> before code needed only to get or set attribute :foreground, > >>> now it will need to also check for a non-nil :contrast-function > >>> and apply that. > >> > >> I don't understand why lisp code would need to know the > >> post-adjustment colors used for display. Can you explain why > >> we'd want to know? > > > > Lisp code that checks or changes a given color attribute is trying > > to check or affect the actual appearance of the face (again, not > > considering merges with other faces etc.). > > > > Doing this breaks the one-to-one relationship between the face's > > attributes and its appearance. >=20 > But there's only a one-to-one relationship if the face is fully > specified --- this patch doesn't change that. That's not true AFAIK, considering the face in isolation. (I said that I was abstracting from complications of face merging and interactions with other display properties.) > > Consider a Lisp function that helps you customize the foreground > > and background colors of an individual face. What it checks and > > what it produces should reflect the face appearance (again, in > > isolation). > > > > Consider a function that lets you modify the foreground of a given > > face incrementally, showing you the effect, WYSIWYG-style, in your > > buffer of C code or whatever. Maybe it increments hue or > > saturation or the blue component. With your feature, what you see > > by its changing attribute `foreground' will presumably "jump" when > > the :contrast-function decides that the new value would be too close > > to the background. >=20 > Yes, that's what would happen, but an editor of this sort --- and > I'm not aware of any that currently exist Doesn't matter whether (a) you are aware of that or (b) whether any actually do exist currently. The point is that any Lisp code like that will likely have its life complicated, and so will users of such code. Oh, and yes, in fact there are "editors of this sort". Both DoReMi and Icicles have commands and other functions that do this kind of thing. They give you WYSIWYG incremental tweaking of face attributes. > --- can just explicitly turn off the adjustment,=20 Just don't turn it on by default. Let users opt in, if they want. Commands like those I described should probably *not* turn this off - not without user say-so. If it is on because the user wants it on then the commands should show what the real effect of incrementing various attribute is - WYSIWYG, even if that means passing through discontinuous jumps (there are already some discontinuities in the hue model, BTW). The commands should not show you a false result, which will then be overridden by The Twiddler as soon as the user has chosen the look she wants. > We should optimize emacs as a text editor, not a precise color > picker or a floor wax. :-) Dunno what that means. It's not either/or: text editor or color picker. If you are proposing to fiddle with Emacs's choosing colors, _especially_ if done automatically in an opaque manner for the user, then you should take seriously such color picking. I thought this feature was being argued for because it supposedly provides more reasonable color picking - getting a better foreground color in some platform-specific, corner cases. If you now make fun of "precise color picking" then I have even less confidence in this whole proposed ball of wax. ;-)