From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: About the :distant-foreground face attribute Date: Tue, 14 Jan 2014 12:44:18 +0100 Message-ID: <52D52312.6070106@swipnet.se> 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> 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 1389699898 9157 80.91.229.3 (14 Jan 2014 11:44:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 11:44:58 +0000 (UTC) Cc: Eli Zaretskii , Chong Yidong , emacs-devel To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 14 12:45:03 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 1W32QY-00058k-99 for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 12:45:02 +0100 Original-Received: from localhost ([::1]:47686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W32QX-0000kj-Qq for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 06:45:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56069) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W32QM-0000fH-TH for emacs-devel@gnu.org; Tue, 14 Jan 2014 06:44:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W32QE-0001eo-Pv for emacs-devel@gnu.org; Tue, 14 Jan 2014 06:44:50 -0500 Original-Received: from mailfe04.swip.net ([212.247.154.97]:49986 helo=swip.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W32Px-0001ZG-DN; Tue, 14 Jan 2014 06:44:25 -0500 X-T2-Spam-Status: No, hits=0.0 required=5.0 Original-Received: from hosdjarv.se (account mj138573@tele2.se [46.59.42.57] verified) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 467178464; Tue, 14 Jan 2014 12:44:22 +0100 Original-Received: from jdvpro.hq.ismobile.com (unknown [176.57.193.190]) (Authenticated sender: jhd) by hosdjarv.se (Postfix) with ESMTPSA id 38EE31A0587; Tue, 14 Jan 2014 11:44:22 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: <52D514FF.7010404@dancol.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 212.247.154.97 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:168350 Archived-At: 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. > > You seem to object to any feature that renders a face in a color other > than what's literally written in the face spec. It may seem that way to you, but it is false. > But that's exactly what > happens when we put gtk_selection_bg_color in a color spec! Why are you > fine with allowing gtk_selection_bg_color as a color (producing a color > that's presumably workable but unknown to a theme writer) but adamantly > opposed to a feature that selects good colors another way? I'm objecting to having the system default colors replaced with generated colors for the default case. What themes other than the default does is irrelevant. We are just talking about defaults here. > > I've produced working code that allows Emacs to act how you prefer *and* > how I prefer based on user configuration. What is your problem with that > code? I have no problem with the code, just the defaults. > Have you responded to the numerous objections to > :distant-foreground with anything other than retrenchment? So far the objections have been mostly opinions. If there was a concrete case or a bug it exposes that would be another issue. The most concrete objection is the case of inheriting faces Yidong brought up in another mail, which indeed is a real problem. >> Also, "look better" is just subjective, a theme >> designer should deside what looks best, not Emacs code. > > And a theme designer can opt not to use the feature or to explicitly > turn it off --- but a theme designer should never have to bother, > because the feature only activates when the contrast is awful, which > happens only when a theme designer screws up or deliberately relies on > system colors. Why should a theme designer rely on system colors? That does not sound like a good theme. Again, the default should rely on system colors, not arbitrary themes. > > Theme designers can specify what exactly gets rendered in both systems. > Why do you care so much about letting theme designers loosen bounds > using a special-purpose face attribute (which you don't even bother to > mirror for changing backgrounds) instead of a general-purpose mechanism? One could think of changing the background instead of the foreground, but the bug report was about the foreground, so the implementation matches. There was no need to implement a general mechanism for this specific bug report. >> That is not a use case. A use case describes what an actual user does >> and in what situation automatically calculates colors enters the picture. > > This entire thread describes the use case. There are abundant examples. > Your objection here is baseless. There is a lot of handwaving and describing of mechanisms, but not one real world example, i.e. what major mode and which font lock faces and possible other faces are involved, and what does the user do to trigger the generated color. >>> :distant-foreground has far too narrow a justification to warrant being >>> a face property by itself. >> >> Also, just an opinion, not based on some documented design rule in any >> Emacs or GNU document. > > So only GNU documents count now, not reasoned arguments? No, but if documentation of some design rule existed it would give weight to your argument. But your statement about :distant-foreground being too narrow is just your personal opinion which you have not motivated with any reasoned argument, just asserted. Jan D.