From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: bind faces? Date: Sun, 14 May 2006 11:33:31 +0900 Message-ID: <873bfds5c4.fsf@catnip.gol.com> References: <878xp5s9zv.fsf@catnip.gol.com> Reply-To: Miles Bader NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1147574035 2977 80.91.229.2 (14 May 2006 02:33:55 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 14 May 2006 02:33:55 +0000 (UTC) Cc: Emacs-Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun May 14 04:33:52 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1Ff6QZ-0000mI-O2 for ged-emacs-devel@m.gmane.org; Sun, 14 May 2006 04:33:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ff6QZ-0000sd-8j for ged-emacs-devel@m.gmane.org; Sat, 13 May 2006 22:33:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ff6QM-0000px-PI for emacs-devel@gnu.org; Sat, 13 May 2006 22:33:38 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ff6QL-0000ph-3W for emacs-devel@gnu.org; Sat, 13 May 2006 22:33:38 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ff6QK-0000pe-Ua for emacs-devel@gnu.org; Sat, 13 May 2006 22:33:36 -0400 Original-Received: from [203.216.5.72] (helo=smtp02.dentaku.gol.com) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Ff6SP-0001c8-CO; Sat, 13 May 2006 22:35:45 -0400 Original-Received: from 203-216-102-135.dsl.gol.ne.jp ([203.216.102.135] helo=catnip.gol.com) by smtp02.dentaku.gol.com with esmtpa (Dentaku) id 1Ff6QG-0001eC-Uu; Sun, 14 May 2006 11:33:33 +0900 Original-Received: by catnip.gol.com (Postfix, from userid 1000) id 59F692F56; Sun, 14 May 2006 11:33:31 +0900 (JST) Original-To: "Drew Adams" System-Type: i686-pc-linux-gnu In-Reply-To: (Drew Adams's message of "Sat, 13 May 2006 18:02:00 -0700") Original-Lines: 75 X-Abuse-Complaints: abuse@gol.com 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:54418 Archived-At: "Drew Adams" writes: > FWIW, you can do it very easily with my `face remapping' patch -- it > ends up being just a normal `let' -- but that's [not?] part of Emacs > yet: > (let ((face-remapping-alist > (cons '(some-face . bold) face-remapping-alist))) > (read-string "blah: ")) > > Sounds promising (though I'm not sure how it works or just what it does). > Never heard of it. Will it be in Emacs 22? 23? Where is it available in the > meantime? It's sitting in my personal source tree; I can cons up a patch. I don't know when it will go in, but I assume it will at some point. RMS approved of the feature generally, but disagreed with some of the implementation details, so I'll have to find the time to either work out something that is both acceptable to him and maintains all desired properties. The essential idea is to make face realization dependent on a variable binding (a "remapping alist" -- the simplest usage just allows you to "bind" face names to point to other faces, but you can also bind faces by feature). Here's the description (the value you see here is because I have the "default" face bound to "variable-pitch" in mail composition buffers): face-remapping-alist is a variable defined in `C source code'. Its value is ((default variable-pitch)) Local in buffer *wide reply to Drew Adams*; global value is nil Documentation: Alist of face remappings. Each element is of the form: (FACE REPLACEMENT...), which causes display of the face FACE to use REPLACEMENT... instead. REPLACEMENT... is interpreted the same way the value of a `face' text property is: it may be (1) A face name, (2) A list of face names, (3) A property-list of face attribute/value pairs, or (4) A list of face names intermixed with lists containing face attribute/value pairs. Multiple entries in REPLACEMENT... are merged together to form the final result, with faces or attributes earlier in the list taking precedence over those that are later. Face-name remapping cycles are suppressed; recursive references use the underlying face instead of the remapped face. So a remapping of the form: (FACE EXTRA-FACE... FACE) or: (FACE (FACE-ATTR VAL ...) FACE) will cause EXTRA-FACE... or (FACE-ATTR VAL ...) to be _merged_ with the existing definition of FACE. Note that for the default face, this isn't necessary, as every face inherits from the default face. Making this variable buffer-local is a good way to allow buffer-specific face definitions. For instance, the mode my-mode could define a face `my-mode-default', and then in the mode setup function, do: (set (make-local-variable 'face-remapping-alist) '((default my-mode-default)))). -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia