From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: reducing defface redundancy Date: Tue, 9 Jul 2002 12:51:17 -0600 (MDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200207091851.g69IpHP13832@aztec.santafe.edu> 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: rms@gnu.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1026240706 31386 127.0.0.1 (9 Jul 2002 18:51:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 9 Jul 2002 18:51:46 +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 17S05S-0008A7-00 for ; Tue, 09 Jul 2002 20:51:46 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17S0Dz-0003Bn-00 for ; Tue, 09 Jul 2002 21:00:36 +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 17S05s-0002Ci-00; Tue, 09 Jul 2002 14:52:13 -0400 Original-Received: from pele.santafe.edu ([192.12.12.119]) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17S050-00024X-00; Tue, 09 Jul 2002 14:51:18 -0400 Original-Received: from aztec.santafe.edu (aztec [192.12.12.49]) by pele.santafe.edu (8.11.6+Sun/8.11.6) with ESMTP id g69IpHB21846; Tue, 9 Jul 2002 12:51:17 -0600 (MDT) Original-Received: (from rms@localhost) by aztec.santafe.edu (8.10.2+Sun/8.9.3) id g69IpHP13832; Tue, 9 Jul 2002 12:51:17 -0600 (MDT) X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec using -f Original-To: miles@gnu.org In-Reply-To: (message from Miles Bader on 09 Jul 2002 10:25:37 +0900) 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:5603 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:5603 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. The user who operates at that level won't be shown, and may not know, at which level the various attributes were specified. If person changes two attributes, and one change affects all terminals while the other does not, that will be a surprise. Here is an idea. Let's eliminate the concept of nested or "common" attribute specs, and make the list look like a simple cond. However, the face to inherit from should be unconditional. Thus, when you want common attributes for face A in various conditions, you put them in another face B and make A inherit from B. This way, either all the attributes specified directly in face A are general or all are specific to a particular kind of terminal. Thus, customizing A is a simple matter, and its behavior is clear. In terms of the actual features of defface, this is almost a return to the way it was a year ago. However, using the inheritance we can get the effect of nesting of specifications.