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 09:28:05 -0800 (PST) Message-ID: <5246cb0e-cb21-4ea0-911c-f2d51bd3364f@default> References: <87bnzo9cja.fsf@gnu.org> <59B7E7FC-48D0-4737-B1BB-FFAC5BA9E07A@swipnet.se> 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 1389115705 6913 80.91.229.3 (7 Jan 2014 17:28:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2014 17:28:25 +0000 (UTC) Cc: emacs-devel To: =?iso-8859-1?B?SmFuIERq5HJ2?= , Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 07 18:28:30 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 1W0aS4-0000cx-4M for ged-emacs-devel@m.gmane.org; Tue, 07 Jan 2014 18:28:28 +0100 Original-Received: from localhost ([::1]:42029 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0aS3-0007gV-Nt for ged-emacs-devel@m.gmane.org; Tue, 07 Jan 2014 12:28:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0aRt-0007Xp-GH for emacs-devel@gnu.org; Tue, 07 Jan 2014 12:28:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0aRk-0004mv-Pq for emacs-devel@gnu.org; Tue, 07 Jan 2014 12:28:17 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:51892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0aRk-0004ml-JB; Tue, 07 Jan 2014 12:28:08 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s07HS6FH028354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 7 Jan 2014 17:28:07 GMT Original-Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s07HS6Ck019617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Jan 2014 17:28:06 GMT Original-Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s07HS6NQ019610; Tue, 7 Jan 2014 17:28:06 GMT In-Reply-To: <59B7E7FC-48D0-4737-B1BB-FFAC5BA9E07A@swipnet.se> 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:167636 Archived-At: > > What is the purpose of this face attribute, newly introduced for > > 24.4? >=20 > Too lazy to read documentation? >=20 > "`:distant-foreground' > Alternative foreground color, a string. This is like > `:foreground' > but the color is only used as a foreground when the background > color is near to the foreground that would have been used. > This is useful for example when marking text (i.e. the region > face). > If the text has a foreground that is visible with the region > face, that foreground is used. If the foreground is near the > region face background, `:distant-foreground' is used instead > so the text is readable." I see. And just how does a user override this automatic "cleverness"? How can a user really make her preference for the face take effect? This kind of DWIMity should always allow users to take control back, and preferably easily. What you think might be best for all users all the time might not be what some user thinks is best for herself. And what about all of the existing code that tests :foreground or otherwise expects it to reflect the actual foreground used? Is that code broken now, because Emacs substitutes a :distant-foreground color behind its back? Must all such code now change to test first one and then the other? When was this design OK'd (and why)? > > First of all, the name :distant-foreground is not intuitive. What > > does "distant" mean in this context? >=20 > The same as in any other context, far removed from something else, > i.e. the background. I agree with Yidong about the name. This is apparently a fallback, alternative color, when (you) think the color specified by the user or program is inappropriate. > > Besides that, the implementation seems rather incomplete. The > > Customize interface, `modify-face', `face-spec-reset-face', and > > other parts of Emacs haven't been updated for the existence of > > this face attribute. >=20 > That is on purpose. It is supposed to be automatically calculated. So what? All the more reason to bring it out into the open, so users can know about it (and try to find some way to work around it, if they like). > > It's unclear what functions like `face-foreground' should now do > > if there's a :distant-foreground. >=20 > No it is not. Yes it is. See above. Search the distributed code and the Internet for uses of "foreground" in Emacs Lisp code. How much of that code now needs to be modified to accommodate this gratuitous change. Was there a real problem, reported by a real user, that this change attempts to fix? Or is this just someone's clever brainchild for making Emacs smarter? > > This all sounds like an invitation for more bugs. In my opinion, > > this feature is a bad idea. +1 > All new features invite new bugs, so are you saying we should never > add new features? All new features should be proposed and discussed, before being cast into the product. That's my humble opinion. > Your opinion is not very interesting, but if you have core for an > alternative approach that would be interesting. Why is any approach needed? What is the (real) problem that needs solving?