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 20:59:23 -0800 (PST) Message-ID: <297547b2-046b-40b7-9bce-f4fc6a4dbd16@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> <432c1d5b-0b1e-4bf9-83ec-551d16f1f515@default> <52D5DC28.9070808@dancol.org> <093a5de1-9e40-46df-b65e-aa0b2d9c60f1@default> <52D605E8.8090608@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 1389762002 19005 80.91.229.3 (15 Jan 2014 05:00:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2014 05:00:02 +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 06:00:05 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 1W3IaC-0000qD-R3 for ged-emacs-devel@m.gmane.org; Wed, 15 Jan 2014 06:00:05 +0100 Original-Received: from localhost ([::1]:52099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3IaC-0007iN-II for ged-emacs-devel@m.gmane.org; Wed, 15 Jan 2014 00:00:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45609) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3Ia1-0007h1-B7 for emacs-devel@gnu.org; Wed, 15 Jan 2014 00:00:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3IZs-00012g-7w for emacs-devel@gnu.org; Tue, 14 Jan 2014 23:59:53 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:35765) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3IZj-0000zh-4d; Tue, 14 Jan 2014 23:59:35 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0F4xQAI004367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Jan 2014 04:59:26 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 s0F4xOen004973 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jan 2014 04:59:25 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 s0F4xONt006927; Wed, 15 Jan 2014 04:59:24 GMT In-Reply-To: <52D605E8.8090608@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: 141.146.126.69 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:168428 Archived-At: > >> I honestly don't understand what you're talking about... > >> If a user hasn't customized an option and has relied on the > >> default, we can modify the default values when we update Emacs. > > > > Yes, yes. Emacs Dev can change the default value. No one says > > otherwise. What the code being added now does is more than that. > > It changes the appearance of the face on the fly - the current > > state, not the default value. > > > > And the rationale you gave for dynamically changing the face > > appearance was that the user had not customized the face away > > from the default spec, so she must not care. That does not > > follow. >=20 > You're contradicting yourself. You acknowledge that changing > defaults is legitimate. Then you say that a user's failure to > customize a face does not give us license to change the way that > face looks by default ^^^^^^^^^^ No. You added "by default". You keep doing that. And I keep explaining that it is the _on-the-fly appearance change_ that does not follow from a user not customizing the default. > when we update Emacs.=20 And you keep repeating that, though I have made it clear that this is not about your having the right to change the default value when you update Emacs. I couldn't be clearer about that. > That's a bizarre claim. Are we supposed to never update faces, > or are we supposed to telepathically know whether the user is > happy with the previous version's default? It's not about the default. It's about a user not having changed the value from the default being taken as an assumption that the user does not care whether you change the face appearance later, on the fly, in some contexts. Not customizing away from the default value says nothing about the user not caring about the appearance. > > The default value for option `foo' is 42. The user does not > > change that. That fact alone does not let you presume that > > the user does not mind if you change the value of `foo' > > on the fly in some contexts to 3000. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Note: "on the fly in some contexts". Nothing about changing the default value. > A better analogy is this: Emacs comes with a foo parameter, > and a user has customized it to 42.=20 No, you have not understood my point, so you are coming up with stuff that is off the mark. You have already reassured us all that if the user customizes face `region' then you will not override that user preference with on-the-fly foreground twiddling. So no one is talking about the case where the user customizes, since that case is apparently not changed - you will continue to respect the user customization, right? The analogy was for the case where the user does *not* change the default value - does not customize the face (the option, in the analogy). That lack of customization does not imply not caring about the value and thus give implicit permission to change it on the fly when you think that is appropriate. > > Yes, the analogy is not exact. You are not changing the > > `foreground' attribute itself. You are changing the face's > > foreground appearance. The `foreground' attribute says nil > > or "LightBlue" or whatever the default defface specifies, > > but on the fly the apparent foreground sometimes ends up > > being "HelloKittyPink" (even though the attribute value has > > not changed). >=20 > Yes, if a user has customized font-lock-function-name-face > to HelloKittyPink No, this is about the `region' face. My analogy was wrt the thing that you will be twiddling, which is the `region' foreground. Customization of other faces or options is not the question. > Once she changes either such that the > font-lock-function-name-face-on-region combination becomes > legible, we use the specified colors without any adjustment. Such that the _combination becomes legible_? That is now the price of your respecting a user customization of `region'? It is not enough that she customizes `region', to have you leave her region highlighting alone? That customization now has to result in a combination that you find legible? In that case, there is no respect of the user's customization. That is respect only when respect doesn't matter and has no cost or effect. Previously you said categorically that if the user customizes `region' then you will attempt no adjustment. Now you say that if she does that, AND if no adjustment is needed, then you will perform no adjustment! You are kind enough to say that if you find that no adjustment is needed you will offer a dispensation from adjusting. When your adjustment would amount to a no-op you will kindly forego it. Gee, thanks. > In the meantime, though, isn't it better for text to be > legible than not? Isn't it better to let the user decide what appearance she wants, whether you think it is appropriate or not? People have several times mentioned the fact that certain libraries intentionally specify foreground and background to be the same color for some faces. This change flies in the face of that use case, even if you limit it to `region' for now (you said you would prefer to generalize it, but would limit it for now). > You would seem to prefer that our user's function names > just disappear when selected It's not about what colors I prefer for the face. It's about what the user prefers. > Users don't care about purity. Whatever that means. No idea what purity you think I'm requesting. But I shudder when I see blanket declarations that users don't care about this or that, even something so meaninglessly abstract as "purity".