From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: reducing defface redundancy Date: 09 Jul 2002 10:25:37 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <877kn3qczq.fsf@tc-1-100.kawasaki.gol.ne.jp> <871yd9q09b.fsf@tc-1-100.kawasaki.gol.ne.jp> <200204220747.g3M7lo301995@aztec.santafe.edu> <200204230024.g3N0OH702333@aztec.santafe.edu> <200204241754.g3OHsIm03235@aztec.santafe.edu> <200207081820.g68IKkT12950@aztec.santafe.edu> Reply-To: Miles Bader NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1026177959 8461 127.0.0.1 (9 Jul 2002 01:25:59 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 9 Jul 2002 01:25:59 +0000 (UTC) Cc: abraham@dina.kvl.dk, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17RjlP-0002CM-00 for ; Tue, 09 Jul 2002 03:25:59 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17Rjtb-0004lB-00 for ; Tue, 09 Jul 2002 03:34:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17RjlZ-0008QO-00; Mon, 08 Jul 2002 21:26:09 -0400 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by fencepost.gnu.org with smtp (Exim 3.35 #1 (Debian)) id 17Rjl9-0008Ph-00; Mon, 08 Jul 2002 21:25:44 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g691PdR01510; Tue, 9 Jul 2002 10:25:39 +0900 (JST) Original-Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g691Pdo20954; Tue, 9 Jul 2002 10:25:39 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g691PcN08921; Tue, 9 Jul 2002 10:25:38 +0900 (JST) Original-Received: from mcspd15.ucom.lsi.nec.co.jp (mcspd15 [10.30.114.174]) by mcsss2.ucom.lsi.nec.co.jp (8.10.2+Sun/3.7Wlsi_mx_6.0) with ESMTP id g691PcK21528; Tue, 9 Jul 2002 10:25:38 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id 620A537D5; Tue, 9 Jul 2002 10:25:37 +0900 (JST) Original-To: rms@gnu.org System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <200207081820.g68IKkT12950@aztec.santafe.edu> Original-Lines: 50 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:5583 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5583 Richard Stallman writes: > So basically the rewritten face spec will look like the original > face-spec except with the user's changes integrated. > > I think users will find this surprising and inconsistent. Can you say why you think this? I think it gets about as close as we can to `doing the intuitive thing' when a someone uses the simple face customization -- it's really impossible to always do things correctly, since we'd have to read the user's mind. Remember that the way I suggest integrating the user's changes follows the structure set up by the face creator, and possible user customizations are one thing to think about when creating the face. > In addition, we want to have buffer-local face definitions, and that > will make this issue even more complex. It depends on how buffer-local face definitions are implemented. My feeling is that there _shouldn't_ be real buffer-specific faces, but rather a way of remapping faces within a buffer. For instance foo-mode could make the `foo-default' be used as the default face within its buffers; if the user want's to change it, they'd have customize `foo-default', not `default' (though the customization widget could notice that there's a buffer-local remapping, and ask the user `do you want to edit the global `default' face, or the `foo-default' face being used in this buffer'). > You can customize a face for the current display, for the current > session, looking at a simple list of attributes, but you cannot save > this. Or you can customize the conditional commands that define the > face, by looking at the whole structure of them. That kind of > customization you can save if you wish. Well that would certainly get rid of the ambiguity, but I suspect that most users would absolutely hate it (I certainly would) -- it attempts to solve a fairly rare problem (face customizations that have surprising results on other display types) by making the _normal case_ more inconvenient and confusing! I think this is a case where it's possible to do a good job automatically most of the time. Since the problems that might arise are fairly minor (the face looks a bit funny), I think they're well justified by the extra convenience and utility for users in the common case from doing things automatically. -Miles -- The secret to creativity is knowing how to hide your sources. --Albert Einstein