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: About the :distant-foreground face attribute Date: Tue, 7 Jan 2014 10:44:26 -0800 (PST) Message-ID: <67166ad2-ed8b-48b2-a0f5-21ec02c5d572@default> References: <<87bnzo9cja.fsf@gnu.org> <59B7E7FC-48D0-4737-B1BB-FFAC5BA9E07A@swipnet.se> <5246cb0e-cb21-4ea0-911c-f2d51bd3364f@default>> <<8361pvsmbk.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389120294 822 80.91.229.3 (7 Jan 2014 18:44:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2014 18:44:54 +0000 (UTC) Cc: jan.h.d@swipnet.se, cyd@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 07 19:45:00 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 1W0be7-0005aX-Bw for ged-emacs-devel@m.gmane.org; Tue, 07 Jan 2014 19:44:59 +0100 Original-Received: from localhost ([::1]:42274 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0be6-00050N-Mz for ged-emacs-devel@m.gmane.org; Tue, 07 Jan 2014 13:44:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41853) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0bdx-000502-FE for emacs-devel@gnu.org; Tue, 07 Jan 2014 13:44:56 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0bdq-0002oQ-AL for emacs-devel@gnu.org; Tue, 07 Jan 2014 13:44:49 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:42063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0bdf-0002nb-DZ; Tue, 07 Jan 2014 13:44:31 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s07IiSmB024089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jan 2014 18:44:29 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s07IiR7p029748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 18:44:27 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s07IiQf8001730; Tue, 7 Jan 2014 18:44:26 GMT In-Reply-To: <<8361pvsmbk.fsf@gnu.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: 156.151.31.81 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:167651 Archived-At: > > All new features should be proposed and discussed, before being > > cast into the product. That's my humble opinion. >=20 > This one was. It solved a bug. The new feature was not proposed on emacs-devel and discussed. It was dreamt up in passing, in one short bug thread, and discussed there by only two developers. > > Why is any approach needed? What is the (real) problem that needs > > solving? >=20 > See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D15668. So the real problem was to have a reasonable background color for face `region' by default. On some platforms a bad color choice was (and apparently still is) being used as the default. That problem does not require this particular "fix". Even that bug thread shows that this was thought to be a nice-to-have new feature that could also take care of this bug. It is not needed, to fix the bug. "It would be nice if one could define a face with a foreground color to be used when foreground and background otherwise are to[o] similar." And from that dream onward to this one (still unimplemented, I hope): >>> It would be nice if... >> >> Sounds like a simple enough extension to defface. > > Or maybe every face should do that by default. IMO, the implementation, and probably the feature itself, is not TRT. Note, BTW, that even the OP had to back you off the first enthusiastic fix, so that he could still customize normally and theme designers would have a simpler time of it. > I envisioned that querying the face for the foreground would > automatically give the "fallback"... At least that was thought of. But is that the case for all code that "queries" a face :foreground or modifies it? Is all such code somehow automatically adjusted now so that it always DTRT? I don't see how that would be the case. It seems that for one tiny piece of the distributed Emacs code that dream behavior was implemented. The problem is all other code that tries to use the :foreground, which attribute might not even be respected (unused, because of a DWIM substitution). Such code thinks that it is getting or changing the foreground color by dealing with just :foreground. But it is wrong, because a clever DWIM feature went behind its back. To DTRT, it will now have to jump through extra hoops.