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: 23 Apr 2002 10:36:51 +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> 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 1019526058 11346 127.0.0.1 (23 Apr 2002 01:40:58 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 23 Apr 2002 01:40:58 +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 16zpIg-0002wt-00 for ; Tue, 23 Apr 2002 03:40:58 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 16zpJd-0005BV-00 for ; Tue, 23 Apr 2002 03:41:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 16zpI8-0007Xi-00; Mon, 22 Apr 2002 21:40:24 -0400 Original-Received: from tyo201.gate.nec.co.jp ([202.32.8.214]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 16zpEz-0007FV-00; Mon, 22 Apr 2002 21:37:09 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g3N1b2V04180; Tue, 23 Apr 2002 10:37:02 +0900 (JST) Original-Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g3N1b0L10719; Tue, 23 Apr 2002 10:37:01 +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 g3N1aqr08562; Tue, 23 Apr 2002 10:36:59 +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 g3N1apg08865; Tue, 23 Apr 2002 10:36:51 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id 822283723; Tue, 23 Apr 2002 10:36:51 +0900 (JST) Original-To: rms@gnu.org System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <200204230024.g3N0OH702333@aztec.santafe.edu> Original-Lines: 52 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:3065 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3065 Richard Stallman writes: > You can think of the grammar I outlined as merely being a > convenient shorthand for the defface user; it's not hard to convert it > into exactly the same `simple but redundant' 2-level format that the UI > uses now. > > I am not convinced that is a good solution to the issue of what > Custom should do. Suppose I give a face one unconditional attribute, > and suppose the user customizes that attribute with Custom. > Should his customization always be recorded only for the one kind > of screen he is actually using? Well, there are two interfaces used by the (current) custom face UI: * The current-display-type-only interface, which is the default. This displays the face used by the current display, and if the user changes something in the face and saves it, the current face attributes become unconditional for all display types (trashing any display-type-conditionalization that was defined by the defface specification for that face). * The many-display-types interface, which the user has to explicitly enable. This displays all the various conditional faces that defface defined, and allows the user to change any of them. This doesn't trash any information. My suggestion of flattening the grammar, and using the current UI, wouldn't change any of this. If the user choose the 2nd (many-display-types) UI, and there's a `common' attribute in the defface spec, he will see that common attribute replicated in each face displayed by the face UI. Having to tweak it for each displayed face might be a little annoying, but it seems to make sense from a UI point of view (a more complex UI that actually mirrored the defface grammar could solve this, perhaps, but the additional complexity could make the situation much more confusing). However, for the 1st UI (current-display-type-only), it might be a useful try and detect changes to `common' attributes and preserve a modified version of the original defface spec, instead of just trashing it as the UI does now. Anyway, my point is that the new grammar won't make anything worse, and may provide some additional leeway for improvement. However, I don't think clever handling of common attributes in the UI is necessarily a requirement for an initial implementation (given that there doesn't seem to be any complaint about the current UI trashing things). -Miles -- o The existentialist, not having a pillow, goes everywhere with the book by Sullivan, _I am going to spit on your graves_.