From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?iso-8859-1?Q?Jan_Dj=E4rv?= Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: About the :distant-foreground face attribute Date: Tue, 14 Jan 2014 21:01:00 +0100 Message-ID: <381DEBDC-71D8-4FAC-BA55-897FEC73A2FC@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> <52D52312.6070106@swipnet.se> <52D58632.3010106@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389729690 23427 80.91.229.3 (14 Jan 2014 20:01:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 20:01:30 +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 21:01:36 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 1W3AB5-0004aU-MW for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 21:01:35 +0100 Original-Received: from localhost ([::1]:50413 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3AB5-0007Op-9Q for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 15:01:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3AAw-0007Og-J4 for emacs-devel@gnu.org; Tue, 14 Jan 2014 15:01:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3AAq-0006Dq-5i for emacs-devel@gnu.org; Tue, 14 Jan 2014 15:01:26 -0500 Original-Received: from mailfe05.swip.net ([212.247.154.129]:55587 helo=swip.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3AAb-0005r8-MH; Tue, 14 Jan 2014 15:01:05 -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 mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 464216436; Tue, 14 Jan 2014 21:01:02 +0100 In-Reply-To: <52D58632.3010106@dancol.org> X-Mailer: Apple Mail (2.1827) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 212.247.154.129 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:168389 Archived-At: Hello. 14 jan 2014 kl. 19:47 skrev Daniel Colascione : > On 01/14/2014 03:44 AM, Jan D. wrote: >> 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. >>>>>=20 >>>>> Calculated foreground colors look better: they resemble the = font-lock >>>>> colors on which they're based. >>>>=20 >>>> For the region case, that would imply the possibility of different >>>> foregrounds for marked text, none which is the actual font-lock = color. >>>=20 >>> 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? >>=20 >> Because the system color foreground is (presumably) choosen to look = good >> together with the system color background. >=20 > Yes, and a color we algorithmically generate from a font-lock face = will *also* look good against that background color, but 1) will be = distinct from other faces replaced for lack of contrast, and 2) will be = visually similar to the pre-highlight face. Have you tried the patch? No. If Emacs generates a color, Emacs desides what looks good. If the = system defines a color, the system (or the user if customized) desides = what looks good. I don't think it matters what I think about colors = generated by your patch, I might even think they look better than many = system defined colors. But as a principle I think the desision is not = Emacs to make *by default*. Users may of course apply customizations to = Emacs and change it. >=20 >>> 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? >>=20 >> 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. >=20 > 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. 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? >=20 >>> 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? >>=20 >> I have no problem with the code, just the defaults. >>=20 >>> Have you responded to the numerous objections to >>> :distant-foreground with anything other than retrenchment? >>=20 >> 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. >=20 > 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, it is a bug fix plain and simple. Informed opinion = sounds like a copout to avoid having to motivate your opinion. If you = can't motivate your informed opinion, it is not worth anything. Design = can be motivated, and so can usability, there are tons of books on the = subjects. I have not read any such arguments here, just assertions that = this is bad. Take "attribute is to narrow". It may very well be, but on what = motivation? How can I know if I want to add another attribute if it = will be to narrow too? Because person X and Y says so? 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. >=20 >>> 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. >>=20 >> 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. >=20 > 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. >=20 >>>> 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. >>>=20 >>> This entire thread describes the use case. There are abundant = examples. >>> Your objection here is baseless. >>=20 >> 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. >=20 > 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. >=20 >>=20 >>>>> :distant-foreground has far too narrow a justification to warrant = being >>>>> a face property by itself. >>>>=20 >>>> Also, just an opinion, not based on some documented design rule in = any >>>> Emacs or GNU document. >>>=20 >>> So only GNU documents count now, not reasoned arguments? >>=20 >> 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. >=20 > 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. Jan D,