From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: Buffer-local faces Date: 04 May 2004 10:40:05 +0200 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: <20040503130350.GA1929@fencepost> <20040503232700.GB9451@fencepost> <20040504095707.GA9691@fencepost> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1083667664 8286 80.91.224.253 (4 May 2004 10:47:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 4 May 2004 10:47:44 +0000 (UTC) Cc: David Kastrup , Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue May 04 12:47:34 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 1BKxSX-0002pf-00 for ; Tue, 04 May 2004 12:47:33 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1BKxSX-0005BE-00 for ; Tue, 04 May 2004 12:47:33 +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 1BKxR2-0003vv-HT for emacs-devel@quimby.gnus.org; Tue, 04 May 2004 06:46:00 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1BKxPv-0003uY-Ra for emacs-devel@gnu.org; Tue, 04 May 2004 06:44:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1BKxPP-0003oh-0v for emacs-devel@gnu.org; Tue, 04 May 2004 06:44:50 -0400 Original-Received: from [212.88.64.25] (helo=mail-relay.sonofon.dk) by monty-python.gnu.org with smtp (Exim 4.30) id 1BKxOy-0004SU-P3 for emacs-devel@gnu.org; Tue, 04 May 2004 06:43:52 -0400 Original-Received: (qmail 74483 invoked from network); 4 May 2004 10:40:49 -0000 Original-Received: from unknown (HELO kfs-l.imdomain.dk.cua.dk) (213.83.150.2) by 0 with SMTP; 4 May 2004 10:40:49 -0000 Original-To: Miles Bader In-Reply-To: <20040504095707.GA9691@fencepost> Original-Lines: 52 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:22700 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:22700 Miles Bader writes: > On Tue, May 04, 2004 at 11:18:21AM +0200, David Kastrup wrote: > > 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. > > I said nothing about the feature freeze. I did not post my patch to `sneak > in under the wire' of the freeze, I posted it because I (1) happened to have > been working on it, and (2) came up with something nice. Again, feature freeze means that people should switch attention away from developing new features -- but that doesn't exclude that we can add things (for a short period) that people have already been working on before the freeze. If those new features are useful (and the changes are not too intrusive), I would prefer to get them into 21.5 rather than wait for 22.x to come out (history shows that major emacs releases don't happen everyday :-| ) I think Miles' approach is quite elegant, as it solves a real problem in a simple and IMO clean way. There may be cases that are not handled by this approach, but it is still a whole lot better than having no approach at all. And even if we find a better or more general approach later on, I believe it can co-exist with Miles' code, as that code works on a pretty low level (implementation-wise). Of course, there may be things that don't work with Miles' patch (fringe faces may be one case -- haven't checked), but it could be fixed during pretest if deemed necessary. I would love to have this feature. > I don't think it's a kludge at all, it's an elegant way of leveraging emacs' > very flexible variable mechanism to achieve the goal -- not only is it almost > trivial to implement, but it would seem to fit very well with the way emacs > modes work. I don't think it is a kludge either. > > Perhaps xemacs has a better way of doing it, I don't know -- I'm afraid I'm > not familiar with xemacs in recent years. As a true GNU emacs evangelist, I've never been familiar with xemacs... -- Kim F. Storm http://www.cua.dk