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 14:38:49 -0800 Message-ID: <52D5BC79.7050706@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> <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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1389739142 13261 80.91.229.3 (14 Jan 2014 22:39:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 22:39:02 +0000 (UTC) Cc: Eli Zaretskii , Chong Yidong , emacs-devel To: Drew Adams , =?ISO-8859-1?Q?Jan_Dj=E4rv?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 14 23:39:08 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 1W3CdX-000401-D1 for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 23:39:07 +0100 Original-Received: from localhost ([::1]:51032 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3CdW-0000dI-VP for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 17:39:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43893) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3CdT-0000dD-AJ for emacs-devel@gnu.org; Tue, 14 Jan 2014 17:39:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3CdR-0003lU-P9 for emacs-devel@gnu.org; Tue, 14 Jan 2014 17:39:03 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:58284) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3CdN-0003kl-Sg; Tue, 14 Jan 2014 17:38:58 -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=hHLfA/v6hWzuiFkFMPSEjajorFzCbg/nGxl517/5Jhs=; b=QQxIozsmxnaTdPp9+dzn1o8WTnQGaUHzpgaHABQeepudkR06qSp/VAhs4B2OqaSJ7O5V4E0HTrbqL8mP2r1t2XR2oCo4bfKIdNRTCUMcJVhHM8zHZUxuygS8NGIx5ExTuxIxc6MPxOhK7G7JdzYQhrHd2KfiuRL3A2WwsAn+O6x2y9dmdd1C2PS1Q4uCfacKtPjDCSx8Ck6voj3Qqi7c4C+bMA/QzXkvSyA+zioyz+wKoK2EZ7526MbAYFrVg+zRfSN9LaveVzFAvwdYRAoy+CFog7oET6ej0KtbP5F3E7rcTqLyIn3YTHpkysYTi5NK6IHj1mYoYN2uX02EF+frCg==; Original-Received: from [2620:0:1cfe:99::1] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W3CdL-00034I-HC; Tue, 14 Jan 2014 14:38:55 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <2798eddb-c6c7-4b73-8bd0-e4bd72f3405e@default> 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:168406 Archived-At: Thanks. This is productive. On 01/14/2014 11:32 AM, Drew Adams wrote: >>> Emacs should act that way by default, as it always has. Anyone >>> who wants automatic foreground twiddling for a given face should >>> ask for that explicitly. Whether that twiddling is to accommodate >>> font-locking or for some other reason. >> >> I don't have a strong opinion about the default, although I lean >> toward the behavior #3 (3b specifically) below since it looks >> blingy and might help attract new users. > > Bof. Today's sparkling blingy is tomorrow's annoying. Fair enough, but it looks like we're going to go with some variant of #3 (according to Stefan's latest message), so we might as well choose the least objectionable #3 variant. > 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? There is a reason we give Isearch > highlighting such a high priority: it should clearly _highlight_ > text - even text that might be font-locked. If I had my druthers, we'd turn on :contrast-function for the default face. It's not generally possible for packages written by arbitrary third parties to coordinate color choices in the presence of arbitrary themes. Most packages can base colors on existing font-lock faces, but font-lock has a limited built-in palette and plenty of packages define entirely new faces with arbitrary colors. Automatic adjustment can make these faces readable no matter the circumstances of their use. I'm trying to be conservative by applying automatic contrast adjustment only to region right now, since it's this face, being based on system colors, that has the highest risk of being unreadable. >>> A face being equal to its default setting does not imply >>> that the user gives Emacs license to change it. >> >> I disagree. If our user leaves a face at the default setting, she's >> giving us *explicit license* to use whatever heuristics we think >> work best. > > And how does she specify to you that the default colors are exactly > what she happens to prefer? How does she produce the same effect as > if the default colors were different and she customized them to be > what the default colors actually are? How does she tell you > "Hands off! This is really what I want!"? She shouldn't have to, because if she chooses reasonable colors, the automatic adjustment will never go into effect. If she really wants to customize the region face so that it is illegible, she can uncheck :contrast-function. >> 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? See above. > 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. Well, yes, we do have such a license. By this logic, we can't change any default ever. >> Right now, it depends on the order in which the faces are merged. >> The last face that specifies a :contrast-function gets to control the >> contrast behavior. > > Users are going to have trouble with that complication. Too much > wondering about what happened and why. Of course, I could be wrong. I don't think it's any more confusing than other aspects of the face model --- or CSS, for that matter. Sure, the model is complex, but it's powerful. >> Right now, region is the only face that specifies a >> contrast-function, and I can't think of another good use case at >> the moment. > > Maybe that in itself should tell you something... See the discussion of generality above. Personally, I'd like to apply automatic adjustment (or other filters) more broadly, but for now, it makes sense to be conservative, which means applying the adjustment only to region. >>> 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. But there's only a one-to-one relationship if the face is fully specified --- this patch doesn't change that. > That means that the Lisp code cannot > just examine or set `foreground' and `background' colors. It will > need to be changed to also invoke the :contrast-function. Or if > that takes effect automatically, it will need to be aware that that > can happen, and perhaps even accommodate it to cancel it out > (depending on the purpose of the Lisp code). > > Consider code that does something based on distance of the current > foreground appearance from some given value - the same kind of thing > you are doing with a given :contrast-function, for instance. It > will no longer be sufficient to just measure the distance to the > current `foreground' attribute value. Now, it will need to invoke > the current :contrast-function too, to accurately estimate the > distance. > >> Also, today, any lisp code that wants to mimic the redisplay face >> combination logic needs to take into account text properties, >> frame-local variables, overlays, display attributes, and so on. It >> would be a big job, and I'm not aware of anyone who's done it. > > I specifically spoke of the color attributes for an individual face, > and separated this from combining faces and 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. Yes, that's what would happen, but an editor of this sort --- and I'm not aware of any that currently exist --- can just explicitly turn off the adjustment, either at the face level or through an overlay in the preview area. We should optimize emacs as a text editor, not a precise color picker or a floor wax. :-)