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 19:52:08 -0800 Message-ID: <52D605E8.8090608@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> <52D5BC79.7050706@dancol.org> <432c1d5b-0b1e-4bf9-83ec-551d16f1f515@default> <52D5DC28.9070808@dancol.org> <093a5de1-9e40-46df-b65e-aa0b2d9c60f1@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 1389757951 14107 80.91.229.3 (15 Jan 2014 03:52:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2014 03:52:31 +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 Wed Jan 15 04:52:38 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 1W3HWv-0006ti-OE for ged-emacs-devel@m.gmane.org; Wed, 15 Jan 2014 04:52:37 +0100 Original-Received: from localhost ([::1]:51927 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3HWv-0000kT-El for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 22:52:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36533) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3HWr-0000he-EJ for emacs-devel@gnu.org; Tue, 14 Jan 2014 22:52:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3HWl-0001QY-Nv for emacs-devel@gnu.org; Tue, 14 Jan 2014 22:52:33 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3HWb-0001GV-Mt; Tue, 14 Jan 2014 22:52:18 -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=QwjcHb6Int3OBUHnkIvZGtS41gAw+O0qpWvISMbDdqk=; b=eyo2Cv+jQy+4Qhuylbpom3KwHAS0spM9iQlV7a1Hx7cSq5fiBU+QTPk0I2vQxFVfxBPvSddQsnLCTu8JYAUvoC9rI+ggLU/LDk/4i5+Br7vkaH8gZQkserH04xcHtfFi7yH2HpHundhwbS5o7XrxV9iGI7gsKSvx6jTFYxgCep/rxZg06+hXD1uVlKduFuZ7IyQrgq8hxvi582WL/67VEyxIK9xOnbQACuj2+G0iZL/rPU9kOF4MqIFaBBC1Al6sPiT/bZlLu1BJlXZARWojShm+CqCkwv4F1qdCYnjbM3x9XJxAJVpvPy1GzzPtoU5wdGsd1snZJwYrBhTXA+fKJQ==; Original-Received: from [2601:8:b200:217:2b5:6dff:fe05:12e5] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W3HWY-0003Vr-7v; Tue, 14 Jan 2014 19:52:14 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <093a5de1-9e40-46df-b65e-aa0b2d9c60f1@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:168417 Archived-At: On 01/14/2014 07:07 PM, Drew Adams wrote: >> 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. 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 when we update Emacs. 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? Let's talk about the case where users have customized *something*. > 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. A better analogy is this: Emacs comes with a foo parameter, and a user has customized it to 42. We ship Emacs with a new parameter, automatically-choose-foo, and default this parameter to t. Under certain conditions, when 42 is useless and when automatically-choose-foo is t, we use 50 instead of the user's configured 42. I think we agree that this kind of automatic-option-overriding behavior is confusing and that we should have a very good reason before adopting it, weighing the benefit of automatically-choose-foo against user surprise. In the particular case of face color, we have a good enough reason. > 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). Yes, if a user has customized font-lock-function-name-face to HelloKittyPink and she runs Emacs on a system where the GTK selection background color is also HelloKittyPink, then under my proposed scheme, we'll render function names that appear in the selection using a slightly different shade of pink or red. If our user is unhappy with this rendering, she can either change font-lock-function-name-face's foreground or change the selection background either by changing the system default background or by changing the region face in Emacs. 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. In the meantime, though, isn't it better for text to be legible than not? You would seem to prefer that our user's function names just disappear when selected and justify this preference with references to data model purity. Users don't care about purity. +--------+--------------------+------------------+ | | Good contrast | Bad Contrast | +--------+--------------------+------------------+ | Auto | Exact color | Color changed | | Adjust | Happy | Maybe happy? | +--------+--------------------+------------------+ | Static | Exact color | Text invisible | | | Happy | Unhappy | +--------+--------------------+------------------+ Note that we're doing this adjustment only for region. rainbow-mode performs a similar adjustment, using a different mechanism, for very similar reasons.