From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Buffer-local faces Date: 04 May 2004 11:18:21 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040503130350.GA1929@fencepost> <20040503232700.GB9451@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083662436 29945 80.91.224.253 (4 May 2004 09:20:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 May 2004 09:20:36 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 04 11:20:29 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKw6H-0006f6-00 for ; Tue, 04 May 2004 11:20:29 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKw6G-0003Wl-00 for ; Tue, 04 May 2004 11:20:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKw5G-0001cn-Gr for emacs-devel@quimby.gnus.org; Tue, 04 May 2004 05:19:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKw4m-0001bR-3c for emacs-devel@gnu.org; Tue, 04 May 2004 05:18:56 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKw4G-0001PR-IZ for emacs-devel@gnu.org; Tue, 04 May 2004 05:18:55 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1BKw4F-0001P8-Nx for emacs-devel@gnu.org; Tue, 04 May 2004 05:18:23 -0400 Original-Received: from fencepost.gnu.org ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.24) id 1BKw4E-0000t9-U1; Tue, 04 May 2004 05:18:23 -0400 Original-To: Miles Bader In-Reply-To: <20040503232700.GB9451@fencepost> Original-Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:22697 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22697 Miles Bader writes: > On Mon, May 03, 2004 at 06:42:10PM -0400, Stefan Monnier wrote: > > > (FACE NEW-FACE MERGE-FACE...), > > > which causes NEW-FACE to be used where FACE normally would. > > > If present, MERGE-FACE... are merged during display with NEW-FACE. > > > > How often would you need MERGE-FACE(s) ? I ask because it seems > > unnecessary since you can also use a new face with a :inherit slot > > instead, right? > > My thought was that this would be convenient for people that want to > just tweak faces in a mode-hook, and allow them to do it without > making a new face. It's annoying to always have to name everything. > Implementation-wise I don't think there's any real cost to allowing > it (the code to merge from a list of faces is already there for the > use of :inherit). I am uncomfortable about the whole change. And the reason has to do with the feature freeze. Now you may argue that the change is not so intrusive as to be likely to trigger new bugs, but that's beside the point. The first question to resolve with regard to a new feature is to figure out how to do it right, not how to circumnavigate the feature freeze best. If we base a decision like this on criteria like a feature freeze, then it may come back to haunt us at a later time. So I think we should first try to resolve what the perceived problem is, what extensions or generalizations of this problem should also be solvable, and what would be the most logical, consistent and useful way to tackle it. _After_ we have made that decision, we can check if it is consistent with the goal to put it in the next version, and have that version appear at a reasonable date. But basing the design on this criterion in the first place seems dubious to me. It just appears that a buffer-local replacement list is a kludge for avoiding a more general scheme of context-dependent faces (probably related to the XEmacs locale/specifier stuff), and maybe other things. If the functionality appears very necessary for the release, one can still decide about a higher level package writer level API for the problem set to be tackled, and implement this API on top of a cheap workaround for a single release, after carefully weighing the benefits. And then replace workaround and the implementation of the API in the next release. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum