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: [PATCH] Re: About the :distant-foreground face attribute Date: Tue, 14 Jan 2014 11:32:14 -0800 (PST) Message-ID: <6435db78-d185-49c9-b1e6-8f62ddc35a12@default> 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> 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 1389727970 3007 80.91.229.3 (14 Jan 2014 19:32:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 19:32:50 +0000 (UTC) Cc: Eli Zaretskii , =?iso-8859-1?B?SmFuIERq5HJ2?= , Chong Yidong , emacs-devel To: Stefan Monnier , Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 14 20:32:56 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 1W39jK-0007rW-QV for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 20:32:54 +0100 Original-Received: from localhost ([::1]:50313 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W39jK-0004zs-Eq for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 14:32:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W39jA-0004p2-9j for emacs-devel@gnu.org; Tue, 14 Jan 2014 14:32:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W39j1-0005jY-Oi for emacs-devel@gnu.org; Tue, 14 Jan 2014 14:32:44 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:38936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W39is-0005ea-J9; Tue, 14 Jan 2014 14:32:26 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s0EJWG0S001178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Jan 2014 19:32:17 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0EJWFOs019158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jan 2014 19:32:16 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s0EJWENl026219; Tue, 14 Jan 2014 19:32:14 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:168384 Archived-At: > FWIW, I like the idea of being able to compute the color > dynamically. I also would welcome a way to specify "color filters", > e.g. a face which "darkens the foreground color". IOW the equivalent > of the floating-point :height settings, but for colors. Instead of :contrast-function (since this should not be limited to foreground contrast), I guess you are essentially arguing to generalize this to a :filter face attribute with a function value that would take the whole face into account, as it is currently defined, and would act on whatever attributes it wants, to update (modify) the face. Is that right? If so, that is not a filter, which is something that just rejects some individuals from a collection (applies a predicate). That is a transformation. The function-valued attribute would be better named :transformer or :transform-function. But why have only one such function for a given face - its designated transformation function, cast in bronze as an attribute? Why wouldn't code just apply whatever transformations it wanted? Daniel proposes that a :filter attribute value be a _list_ of transformation functions. But the same question arises: why favor one list of such functions by putting into an attribute value. The same questions can be posed for whatever foreground-enhancing transformation you are currently envisioning. Why have a face attribute for that? Why not just perform whatever foreground modification your code thinks is needed, directly? What is the value in promoting that particular transformation function into a face attribute?=20 Is it to give users control over this feature by using Customize? If so, why not do that as we usually do: provide your (hopefully optional, hopefully opt-in) feature via a user option? With the option turned on by the user, your automatic foreground enhancing would take effect for some list of faces (e.g. just `(region)').