From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: face-remapping patch Date: Thu, 29 May 2008 18:27:33 +0200 Message-ID: <86fxs1nki2.fsf@lola.quinscape.zz> References: <5CB5F5E5-9239-40A8-A3B2-5F49B94E27B7@gmail.com> <85lk1ui3i0.fsf@lola.goethe.zz> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1212078581 11032 80.91.229.12 (29 May 2008 16:29:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 May 2008 16:29:41 +0000 (UTC) Cc: David Reitter , Miles Bader , Emacs-Devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 29 18:30:21 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K1l0z-0001BK-3M for ged-emacs-devel@m.gmane.org; Thu, 29 May 2008 18:30:09 +0200 Original-Received: from localhost ([127.0.0.1]:39912 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1l08-0007GL-J3 for ged-emacs-devel@m.gmane.org; Thu, 29 May 2008 12:29:16 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K1kyV-0006tR-QG for emacs-devel@gnu.org; Thu, 29 May 2008 12:27:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K1kyV-0006tF-Fe for emacs-devel@gnu.org; Thu, 29 May 2008 12:27:35 -0400 Original-Received: from [199.232.76.173] (port=41554 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K1kyV-0006tC-4T for emacs-devel@gnu.org; Thu, 29 May 2008 12:27:35 -0400 Original-Received: from mail.quinscape.de ([212.29.44.217]:41606) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K1kyU-0006BF-KP for emacs-devel@gnu.org; Thu, 29 May 2008 12:27:34 -0400 Original-Received: (qmail-ldap/ctrl 14352 invoked from network); 29 May 2008 16:27:32 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by quinx.quinscape.de (qmail-ldap-1.03) with SMTP for ; 29 May 2008 16:27:32 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id C69948F054; Thu, 29 May 2008 18:27:33 +0200 (CEST) In-Reply-To: (Stefan Monnier's message of "Thu, 29 May 2008 11:56:14 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-AntiVirus: checked by AntiVir MailGate (version: 2.1.3-2; AVE: 7.8.0.24; VDF: 7.0.4.113; host: quinx) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:97987 Archived-At: Stefan Monnier writes: >>> To improve on this, I think we'd have to move to something more like >>> XEmacs's specifiers. But I haven't even seen any proposal for such >>> a thing yet. > >> Proposal: allow a third argument for make-local-variable. > > That's for variables, not faces. Yes, quite so. I was trying to brainstorm about one mechanism at a time. I am not convinced that it is a good idea to treat faces completely differently. > But, yes, maybe we should rethink face-settings along similar lines: > > (set-face-attribute FACE LOCUS &rest ARGS) > > The first difficulty is to figure out how to integrate such a thing > with the settings coming from X resources, from defface specs, from > frame parameters (font & back/foreground colors, IIRC), ... > > Note that it would be a good opportunity to try and make this whole > code more efficient as well, so that all face settings don't get > redundantly recomputed everytime we create a new frame. > > I guess the defface spec and the X resources could be turned into > terminal-local settings computed everytime a new terminal is created > (and everytime a new face is created, of course). Something like that. We already have too many different mechanisms at work for similar things. Unifying the approaches (even if we find out that unifying the underlying internals is not feasible) would, I think, in general be helpful for application programmers. -- David Kastrup