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:39:14 -0800 Message-ID: <52D5A072.5010508@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 1389731967 17338 80.91.229.3 (14 Jan 2014 20:39:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 20:39:27 +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:35 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 1W3Alq-0006WH-UK for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 21:39:35 +0100 Original-Received: from localhost ([::1]:50569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3Alq-0002eY-Fl for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 15:39:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3Alk-0002Wr-Gk for emacs-devel@gnu.org; Tue, 14 Jan 2014 15:39:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3Ali-0000SX-Hi for emacs-devel@gnu.org; Tue, 14 Jan 2014 15:39:28 -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-8h; Tue, 14 Jan 2014 15:39:22 -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=c2MGj+hsrFco+ChciMbMvJVLtgwDAGoxvUhocOyMyy0=; b=FrWBbur5pIOpO12K15QrPo+RML8QKSRnGWaZt/sDQ9FiA1dfohNuLrRdU5OstIY1W1qGBNpdN/8ZHuod3DyvZcmoSO3xs5tc01GRSTczpAWZhVBl59wAJ03j3q2Z2G7SBZtNB9vCPrJd+lfDDCJZ75J7yEaRCEYoTcQaQd54bnhUE2HD5EWQ60iJB3CAi4Zsxm5b9ZNPzmMTelu37uw0iH0aDM8D8V0EBQlXc8aEDESRoA1A5r05BnfmwWyI3J33pQIrylxHuHC3+KqZlMUwYdcXNOvTfYDpXYxZJ+ZhAT5tXG2bvwtpNp4W67Azv/5tbUTMjilYTnEy+oPef9aP4w==; 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 1W3Alc-0002qI-Rl; Tue, 14 Jan 2014 12:39:20 -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:168392 Archived-At: I don't feel we're converging on a consensus solution. If you're not going to budge on this, I propose simply reverting the code to what it was in 24.3 and unconditionally using the system selection foreground and background colors. I'd rather have that than :distant-foreground and its hard-coded policy. Also, can you please configure *your* mailer to wrap long lines? On 01/14/2014 12:01 PM, Jan Djärv wrote: >>>> 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. >> >> We already replace the system default colors with colors from font-lock faces. > We at least try to use text selection colors and tool tip colors > where > we can. That's simply not true. We're now replacing the system selection foreground with colors from font-lock faces. This entire thread is about solving the problems that arise from this decision. > For some ports of Emacs this is harder (i.e. not using Gtk+). I > haven't seen any system defined colors that corresponds exactly to an > Emacs font-lock face, Emacs defines tons of faces that most GUI system > don't. So yes, we replace system colors, when Emacs can't figure out the > system color. What else should Emacs do? Replacing the system selection foreground color is a choice. If we're going to make the leap to overriding system color preferences, we shouldn't feel constrained by needing to respect system preferences. >>>> 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. >> >> Problems with usability in UI or API design don't result in clear >>"bugs" in the same way that logic errors or crashes do. Fixing them >> relies on judgment, and that relies chiefly on informed opinion. You >> can't dismiss others' opinions about this feature while not subjecting >> your own to the same treatment. > I have not put forth any usability or design argument for the > current > implementation, Your position seems inconsistent. You say that it's okay to override system colors with explicitly-specified RGB values, but not okay to override these preferences with generated colors. You argue that the system selection foreground is presumably chosen to look good against the system selection background, but ignore the fact that font-lock faces aren't. > it is a bug fix plain and simple. Informed opinion > sounds like a copout to avoid having to motivate your opinion. Bullshit. My patch is just as much a bugfix as :distant-foreground. What makes your bugfix better than mine? > That would be OK if X > and Y where appointed design chiefs for Emacs or this aspect of Emacs. I > don't think any value of X or Y has been so appointed, except for the > Emacs maintainers. And Stefan hasn't stated a position, except to say that the general idea of algorithmically-derived face color is acceptable in some circumstances. >>>> 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. >> >> You are not responding to the point I make in the text you quote. >> I >> don't know why a theme designer would use system colors either. That's >> not the point. I'm saying that explicitly-chosen themes should never >> trigger the code under discussion if they're well-designed. > > Okay. I don't know why that is relevant though. It's relevant because you're arguing as if we arbitrarily replace user-specified colors with algorithmically-derived colors. We only do that when the colors we would otherwise use are not legible against each other. Any well-designed theme will never trigger this code because it will never produce an illegible color combination. If it did, it would be better for users for Emacs to override the theme and produce text users can read. In any case, themes probably won't set :contrast-function, so it won't matter. >>>>> 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. >> >> Message-ID: <52D4A23E.4030802@dancol.org> >> From: Daniel Colascione >>> So to put the discussion in more concrete terms: say I run a stock >>> GTK3 Emacs on a system with a background color exactly equal to >>> "Blue1", which is the color we use for font-lock-function-name-face. >>> I visit xfaces.c, search for "UNSPECIFIEDP", and hit C-a C-SPC C-e. >>> What colors do you propose we use for the text "UNSPECIFIEDP" on that >>> line? > > You can do that today and see which color gets used. > It is the one Emacs trunk uses today, the Gtk selection foreground 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. >> >> I'm not the only one who's expressed concerns about the design of the feature. > > Good, then you should be able to motivate your design rules with no effort. This is incredibly frustrating. I've *already* "motivated" my concerns, as have Drew Adams and Chong Yidong. Briefly, the proposed face attribute addresses one specific problem and not easily-foreseeable related problems, hard-codes a particular policy choice for solving that problem. It requires that we support this particular hard-coded policy choice for all time, since we can't easily remove face attributes once we've added them. Automatically adjusting colors for contrast is subtle and applicable to *any* situation where we need to combine faces for disparate sources. Further, a single foreground-color attribute is inadequate for the general case, since there's no guarantee that the "distant" color contrasts against the background any better than the normal color does. In practice, your feature is only good for the region face, since there, we can specify the system selection background. That's what I mean when I say it's "too narrow": your solution is a special-case hack that doesn't fully address the issues surrounding the problem it means to solve. If we fully solve the problem after shipping distant-foreground, we'll just have to support *both* solutions forever.