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: Mon, 13 Jan 2014 18:41:47 -0800 Message-ID: <52D4A3EB.9040007@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> <52D47FD5.6060402@dancol.org> 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 1389667316 31440 80.91.229.3 (14 Jan 2014 02:41:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 14 Jan 2014 02:41:56 +0000 (UTC) Cc: Eli Zaretskii , =?ISO-8859-1?Q?Jan_Dj=E4rv?= , Chong Yidong , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 14 03:42:04 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 1W2tx6-0007RV-2j for ged-emacs-devel@m.gmane.org; Tue, 14 Jan 2014 03:42:04 +0100 Original-Received: from localhost ([::1]:46223 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2tx5-00048T-Mz for ged-emacs-devel@m.gmane.org; Mon, 13 Jan 2014 21:42:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49624) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2tx2-000489-BN for emacs-devel@gnu.org; Mon, 13 Jan 2014 21:42:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W2tx1-0003Zu-Hi for emacs-devel@gnu.org; Mon, 13 Jan 2014 21:42:00 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:55165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W2tww-0003ZH-OZ; Mon, 13 Jan 2014 21:41:55 -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=20rkgsq95+fMiaRJg/igyd7TS2qPgjMii/mqwahkfB4=; b=mzHtKx8enlayP2QGdmald180lFVGjg0B7i/eB/OGW34EAc1lmaibp0LoTyx5k99K1RRU0dZQmptOwW61dlINLmciq4AvDZc5pR2NhNxHf7yMWjF+gI1XB+C8H9x0PB0cjp+mjeOZoJluZ30VeHhSfyGijJf5jov14QZ1YJT7YfrrPMVlacYwHci3sRzv8DsnG1jk3lS3g/RXwIEz2r0s1gzfPyJmV5yEGImeJmN9T4c8W14dd34/K0rJwfXrzVsfeuZeZDjrdTsrS+BXSJBpInOGAStQUYvPwJ+rSYkvR2XyAcuMAD+NUA8hlNDYTyd2U1q+YNIC+mZWhuIxEUgiHQ==; Original-Received: from [2620:0:1cfe:a0:863a:4bff:fec8:e538] by dancol.org with esmtpsa (TLS1.0:DHE_RSA_CAMELLIA_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1W2twv-0001EA-MH; Mon, 13 Jan 2014 18:41:53 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: 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:168338 Archived-At: On 01/13/2014 05:45 PM, Stefan Monnier wrote: >>>> If you want the :distant-foreground behavior, it can be accommodated >>>> in this patch. This patch also permits other schemes that some users >>>> might find more useful. We should push policy to user customization >>>> when possible instead of hardcoding policy in the logic of >>>> face attributes. >>> 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. >> You can write something like that in my setup --- we actually >> call :contrast-function on every face realization. There's no reason it has >> to act only on certain conditions, although that's what all the existing >> implementations do. > > There are some differences, tho, w.r.t what the function sees: > does it see the fully merged face, or does it only see the face > merged up to the point where the filter appears. Indeed. Well, let's honor the long tradition of choosing the policy that's easier to implement. :-) We can support our hypothetical :filter (which we should rename :post-realize-filter) without too much change to the face logic using this scheme: 1) Define LFACE_FILTER_FUNCTION as a possibly-empty list of filter functions 2) When we combine faces A and B, A+B's LFACE_FILTER_FUNCTION is the concatenation of A's filter list and B's filter list. As an exception, if B's filter list is of the form (t . OVERRIDE-FILTER-LIST), then A+B's filter list is just OVERRIDE-FILTER-LIST. 3) On realization, we pass the resulting face attributes through each filter function, then use the resulting attributes for display. Later, if we need to, we can add a regular :filter that works face-by-face, like height.