From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Joel Mccracken Newsgroups: gmane.emacs.devel Subject: Re: About the :distant-foreground face attribute Date: Tue, 7 Jan 2014 13:09:09 -0500 Message-ID: References: <87bnzo9cja.fsf@gnu.org> <59B7E7FC-48D0-4737-B1BB-FFAC5BA9E07A@swipnet.se> <5246cb0e-cb21-4ea0-911c-f2d51bd3364f@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389118171 5628 80.91.229.3 (7 Jan 2014 18:09:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2014 18:09:31 +0000 (UTC) Cc: =?iso-8859-1?Q?Jan_Dj=E4rv?= , Chong Yidong , emacs-devel To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 07 19:09:37 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 1W0b5q-0000rF-CH for ged-emacs-devel@m.gmane.org; Tue, 07 Jan 2014 19:09:34 +0100 Original-Received: from localhost ([::1]:42178 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0b5p-0003nh-Oq for ged-emacs-devel@m.gmane.org; Tue, 07 Jan 2014 13:09:33 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35256) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0b5g-0003nT-Gy for emacs-devel@gnu.org; Tue, 07 Jan 2014 13:09:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0b5b-00017v-Gb for emacs-devel@gnu.org; Tue, 07 Jan 2014 13:09:24 -0500 Original-Received: from mail-qa0-x234.google.com ([2607:f8b0:400d:c00::234]:47470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0b5V-000171-R5; Tue, 07 Jan 2014 13:09:14 -0500 Original-Received: by mail-qa0-f52.google.com with SMTP id j15so319317qaq.39 for ; Tue, 07 Jan 2014 10:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YTElFxlAs7rA0lUNtphZ+0iBa1a7EcVe/vvUgUV47v0=; b=c0N5pmJ0MWSJY13CKynX8bvt6Hbgnfhzx19tqPSjAr+F6AKjSZCU3wAq8nhjVwdaTu Zj2eE/swt0W870dTu2WW/RM/hFncqWuPM5D7nU6dngURo3YeuuoBxBeZ5nwAUPujZASQ NY+xCR1UWt7cKxi/9jjdp6weeToSZa3boKzclTeNMHnHVU417zLTj10G3jRrk5tRw1t8 MBk/k2ZP4u/h1pRtdJ5XBQujhI6eoG0EGAq29Pb3e4HVJLzk057T/GF8KFax5+ShoYm2 zdOCWgd0h0zPPNXp/4TiVrYNcWeglHT7sRZAiJ52CGLCP1qkVJUBxXdGcLAqQ3qj09Cj k/+A== X-Received: by 10.224.43.72 with SMTP id v8mr190313698qae.52.1389118152885; Tue, 07 Jan 2014 10:09:12 -0800 (PST) Original-Received: from [192.168.1.18] (pool-71-182-237-73.pitbpa.east.verizon.net. [71.182.237.73]) by mx.google.com with ESMTPSA id gf3sm101695388qeb.17.2014.01.07.10.09.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Jan 2014 10:09:11 -0800 (PST) X-Priority: 3 In-Reply-To: <5246cb0e-cb21-4ea0-911c-f2d51bd3364f@default> X-Mailer: Apple Mail (2.1510) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c00::234 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:167648 Archived-At: It seems like "contrast" could be used to explain the difference in a = more intuitive way.=20 On Jan 7, 2014, at 12:28 PM, Drew Adams wrote: >>> 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." >=20 > 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? >=20 > 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. >=20 > 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? >=20 > When was this design OK'd (and why)? >=20 >>> 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. >=20 > 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. >=20 >>> 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. >=20 > 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). >=20 >>> It's unclear what functions like `face-foreground' should now do >>> if there's a :distant-foreground. >>=20 >> No it is not. >=20 > 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. >=20 > 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? >=20 >>> This all sounds like an invitation for more bugs. In my opinion, >>> this feature is a bad idea. >=20 > +1 >=20 >> All new features invite new bugs, so are you saying we should never >> add new features? >=20 > All new features should be proposed and discussed, before being cast > into the product. That's my humble opinion. >=20 >> Your opinion is not very interesting, but if you have core for an >> alternative approach that would be interesting. >=20 > Why is any approach needed? What is the (real) problem that needs > solving? >=20