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 21:12:44 -0800 Message-ID: <52D618CC.8090109@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> <52D605E8.8090608@dancol.org> <297547b2-046b-40b7-9bce-f4fc6a4dbd16@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 1389762778 25883 80.91.229.3 (15 Jan 2014 05:12:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2014 05:12:58 +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 06:13:06 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 1W3Iml-0007al-V1 for ged-emacs-devel@m.gmane.org; Wed, 15 Jan 2014 06:13:04 +0100 Original-Received: from localhost ([::1]:52145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3Iml-0001xv-5j for ged-emacs-devel@m.gmane.org; Wed, 15 Jan 2014 00:13:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3Imh-0001xf-4q for emacs-devel@gnu.org; Wed, 15 Jan 2014 00:13:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3Imf-00055X-VR for emacs-devel@gnu.org; Wed, 15 Jan 2014 00:12:59 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:59304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3Imb-00052R-Ub; Wed, 15 Jan 2014 00:12:54 -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=vsc4yPvgb/DipSzcO2TOCiH5Phvfrjb+xAcmDCGA5lY=; b=VfKv1bHCeRqpVOzYwIao8okUmwOpsVR/eX2EMU0IEUbp+jfEYUV9vq2k42RCtaI6vhIiG5oJJP8Ez9J0qDa0ZHSRkc3jOq9r55zoyEr4Yv9n8/x2Wi3/rn20ETizAVUP4+mhlWvdu4ZSRFydTDHTq9DV4H20wvqCcj81GeguE+8T0cGE8TFN356qEsLx7EaOGyUdY3rpF4xPra8ld8ezSj8fXiU1a46N3c9qO0bKOo4bVGRnHg/8bJC9pMpJSKf897RACqSkI8LDgVPZy71KMHdH3QIGYxyZhSvbKKyROFM7L2FBzDQLEGs3XVSsZN1hYDUolUBR0+xYaVQAOdvnqQ==; 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 1W3ImZ-0003eb-CI; Tue, 14 Jan 2014 21:12:51 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <297547b2-046b-40b7-9bce-f4fc6a4dbd16@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:168429 Archived-At: On 01/14/2014 08:59 PM, Drew Adams wrote: >> 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. So your objection is just to the same face appearing in different colors in different contexts? You must loathe XEmacs specifiers, frame-local face-remapping tables, and the display-spec portion of face specifications. >>> 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 > > 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. The foreground of the `region' face isn't being changed. In this instance, `region' doesn't have a foreground face set. If the user customizes the region face, this entire discussion doesn't apply because, at that point, the user can set whatever colors are desired and (if necessary) turn off the contrast adjustment. >> 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). The purpose of using a face with identical foreground and background colors would be better served with a text or overlay property. Besides: even in 24.3, highlighting a part of the buffer marked with such a face makes the hidden text visible. >> 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. Do you really think users would prefer invisible text? >> 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". Your entire objection to this feature seems to be driven by some kind of Platonic ideal of settings as values that Emacs uses and consistently and that never change without explicit user interaction. Preserving these properties isn't worth much, especially if it leads to a worse user experience.