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 16:54:00 -0800 Message-ID: <52D5DC28.9070808@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> 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 1389747251 1719 80.91.229.3 (15 Jan 2014 00:54:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2014 00:54:11 +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 01:54:18 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 1W3EkL-0005Mo-RD for ged-emacs-devel@m.gmane.org; Wed, 15 Jan 2014 01:54:18 +0100 Original-Received: from localhost ([::1]:51419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3EkL-0008Hb-Ik for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 19:54:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3EkH-0008HW-N6 for emacs-devel@gnu.org; Tue, 14 Jan 2014 19:54:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W3EkG-0005vP-HS for emacs-devel@gnu.org; Tue, 14 Jan 2014 19:54:13 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:58634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W3EkD-0005ur-6Q; Tue, 14 Jan 2014 19:54:09 -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=HUS+y0+pByHmiRGNWwQ2D1/+tJyhfeGvvwQYSPBrPRI=; b=JaXVtCdUdAkmuNhf5+emb0jaPj/eIdgrbQkQVH2Ydw3tciDCx07fMbCx1YBJaCCxrp3t+SluqWViT0uCIQd/tWCODL3+7ukXVmzQLtm+zBGfcDjuUm3WIr4GTE3zBEHtPRMVLjepPHhrm+6i2nkQTgpj2GueXrH6kOnzdvBmNCGs/fJQ5Dn9uvo5HOAQ0SO7VZCxpX0HALANwK9Cre+YfCefhvmmT6afm+vgPI8cen0N6e7P3KIEn974ILZuEdAbqajzzfWWdPBM1BEWbDh1ebSXoLwGKQbMesEl54J4rx1oC3MAJd0691TrXNtEL435b+W0j+k9tC6rHf+CVu/9wg==; 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 1W3EkA-0003Gw-MB; Tue, 14 Jan 2014 16:54:06 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <432c1d5b-0b1e-4bf9-83ec-551d16f1f515@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:168411 Archived-At: On 01/14/2014 04:31 PM, Drew Adams wrote: >>>> If a user never expressed a preference with respect to foreground >>>> and background colors, there's no contract to violate. >>> >>> And how does she express that preference, if it happens to >>> coincide with the default colors? >> >> See above. > > So she has to opt out. She has to realize that she really wants > the default color attribute values, which she never really sees > because the automatic tweaking is on by default. She sees the default attributes --- system selection background, font-lock foreground --- almost all the time. Can you give me a concrete example of a situation in which this scheme might be problematic? > And then she > has to explicitly opt out, to get those colors she has finally > realized she wants. We're talking about a default Emacs configuration. Users want legible text, and they want Emacs to look like their other applications. We're obliging them. > Just turn it off by default. For those few platforms that are > ill-designed enough to present a problem, she will figure out > whether she wants to remedy that problem by opting into the > automatic twiddling. If there really is a visible problem on > her platform then she will see it and will be able to make an > informed choice. Call out this clever compensation in the doc. Whether we have a contrast problem has absolutely nothing to do with how well the system is designed. The variable here is the default selection background. Or are you claiming that any system that provides a selection background color that conflicts with an Emacs font-lock face is badly designed? That's a pretty Emacs-centric view of the world. I strongly disagree that we should show users illegible text and tell them how to correct the problem in the documentation. Users don't change defaults when evaluating a product. Emacs should work by default. Users should have to opt into breaking their editing environment. >>> What you are saying is like saying that you think you have a >>> license to change the value of option `default-frame-alist' >>> automatically, if the current value is nil, because that's also >>> the default value. >> >> Well, yes, we do have such a license. By this logic, we can't change >> any default ever. > > Did you notice "automatically" and "current value" in that sentence? > I'm not talking about the license of Emacs Dev to redefine the > _default_ value. I'm talking about license to change the _current_ > value of an option, on the fly, automatically, behind the user's > back... - just because the current value happens to coincide with > the default value (`nil' in this case). > > A user's not customizing an option away from the default value is > not implicit permission for Emacs to twiddle the current value to > something different. I honestly don't understand what you're talking about. Perhaps you can rephrase it? If a user has customized an option, we don't touch it. If a user hasn't customized an option and has relied on the default, we can modify the default values when we update Emacs. All customization variables work this way. Faces are not special. Users with custom themes won't see a difference. `nil' isn't a foreground color. It's the absence of a foreground color. If a user has customized region and set the region foreground color to nil, she's explicitly asked Emacs to combine the region foreground with whatever other face happens to be in the buffer. We're just performing this combination in a way that yields visible text. Nobody has ever deliberately told Emacs to make text illegible when highlighting the selection. You're going on about some kind of intellectual purity and ignoring the reality of what users will actually see.