From mboxrd@z Thu Jan  1 00:00:00 1970
Path: main.gmane.org!not-for-mail
From: Richard Stallman <rms@gnu.org>
Newsgroups: gmane.emacs.devel
Subject: Re: reducing defface redundancy
Date: Mon, 22 Apr 2002 01:47:50 -0600 (MDT)
Sender: emacs-devel-admin@gnu.org
Message-ID: <200204220747.g3M7lo301995@aztec.santafe.edu>
References: <877kn3qczq.fsf@tc-1-100.kawasaki.gol.ne.jp>
	<rj4ri62weq.fsf@zuse.dina.kvl.dk> <871yd9q09b.fsf@tc-1-100.kawasaki.gol.ne.jp>
Reply-To: rms@gnu.org
NNTP-Posting-Host: localhost.gmane.org
X-Trace: main.gmane.org 1019463974 27995 127.0.0.1 (22 Apr 2002 08:26:14 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Mon, 22 Apr 2002 08:26:14 +0000 (UTC)
Cc: abraham@dina.kvl.dk, emacs-devel@gnu.org
Return-path: <emacs-devel-admin@gnu.org>
Original-Received: from quimby.gnus.org ([80.91.224.244])
	by main.gmane.org with esmtp (Exim 3.33 #1 (Debian))
	id 16zZ9K-0007HQ-00
	for <emacs-devel@main.gmane.org>; Mon, 22 Apr 2002 10:26:14 +0200
Original-Received: from fencepost.gnu.org ([199.232.76.164])
	by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian))
	id 16zZ9w-0006yI-00
	for <emacs-devel@quimby.gnus.org>; Mon, 22 Apr 2002 10:26:52 +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 16zYad-0005LK-00; Mon, 22 Apr 2002 03:50:23 -0400
Original-Received: from pele.santafe.edu ([192.12.12.119])
	by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian))
	id 16zYYB-00051p-00; Mon, 22 Apr 2002 03:47:51 -0400
Original-Received: from aztec.santafe.edu (aztec [192.12.12.49])
	by pele.santafe.edu (8.11.6+Sun/8.9.3) with ESMTP id g3M7loa01516;
	Mon, 22 Apr 2002 01:47:50 -0600 (MDT)
Original-Received: (from rms@localhost)
	by aztec.santafe.edu (8.10.2+Sun/8.9.3) id g3M7lo301995;
	Mon, 22 Apr 2002 01:47:50 -0600 (MDT)
X-Authentication-Warning: aztec.santafe.edu: rms set sender to rms@aztec using -f
Original-To: miles@gnu.org
In-Reply-To: <871yd9q09b.fsf@tc-1-100.kawasaki.gol.ne.jp> (message from Miles
	Bader on 21 Apr 2002 11:00:16 +0900)
Errors-To: emacs-devel-admin@gnu.org
X-BeenThere: emacs-devel@gnu.org
X-Mailman-Version: 2.0.9
Precedence: bulk
List-Help: <mailto:emacs-devel-request@gnu.org?subject=help>
List-Post: <mailto:emacs-devel@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=subscribe>
List-Id: Emacs development discussions. <emacs-devel.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/emacs-devel>,
	<mailto:emacs-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/emacs-devel/>
Xref: main.gmane.org gmane.emacs.devel:3000
X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3000

    Remember, by default (unless you select `Show All Display Specs'), the
    face customization widget basically tosses out all the clauses of the
    current defface spec except the active one.  So, 99% of the time, the
    user only deals with the _current_ definition of a face, and is happy.

Simple face customization is clean now because it affects just one
alternative, and it is easy and well-defined to select just the
alternative that applies.

With your propose defface change, the attributes actually specified
would not come from a single alternative in a simple way.  So the
customization of the active parts of the defface spec would raise
difficult issues.  If the user adds a new attribute, where in the
structure does it go?