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: kill ring menu Date: 08 May 2002 15:50:32 +0900 Sender: emacs-devel-admin@gnu.org Message-ID: References: <1020022891.27106.142.camel@space-ghost> <200204290505.g3T55t006146@aztec.santafe.edu> <1020059236.31789.358.camel@space-ghost> <200204300519.g3U5Js306727@aztec.santafe.edu> <1020320725.27616.54.camel@space-ghost> <200205031825.g43IPuD00768@aztec.santafe.edu> <1020502030.5286.25.camel@space-ghost> <200205051746.g45Hk5P01808@aztec.santafe.edu> <1020662101.5288.76.camel@space-ghost> <87helleq50.fsf@tc-1-100.kawasaki.gol.ne.jp> <1020725723.5138.127.camel@space-ghost> <1020743734.5288.153.camel@space-ghost> <200205072007.g47K7bv04781@aztec.santafe.edu> <1020803891.5288.198.camel@space-ghost> <878z6vtrqr.fsf@tc-1-100.kawasaki.gol.ne.jp> <1020837914.1291.390.camel@space-ghost> 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 1020840861 8714 127.0.0.1 (8 May 2002 06:54:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 8 May 2002 06:54:21 +0000 (UTC) Cc: 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 175LLA-0002GR-00 for ; Wed, 08 May 2002 08:54:20 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 175LTB-0004Ex-00 for ; Wed, 08 May 2002 09:02:37 +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 175LKx-0008Ez-00; Wed, 08 May 2002 02:54:07 -0400 Original-Received: from tyo202.gate.nec.co.jp ([210.143.35.52]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 175LIe-00087J-00; Wed, 08 May 2002 02:51:45 -0400 Original-Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g486pYR23690; Wed, 8 May 2002 15:51:34 +0900 (JST) Original-Received: from mailsv.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 g486pXR15654; Wed, 8 May 2002 15:51:33 +0900 (JST) Original-Received: from mcsss2.ucom.lsi.nec.co.jp ([10.30.114.133]) by mailsv.nec.co.jp (8.11.6/3.7W-MAILSV-NEC) with ESMTP id g486oXB02778; Wed, 8 May 2002 15:51:30 +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 g486oXK18314; Wed, 8 May 2002 15:50:33 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id 8DD1F3722; Wed, 8 May 2002 15:50:32 +0900 (JST) Original-To: Colin Walters System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <1020837914.1291.390.camel@space-ghost> Original-Lines: 29 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:3706 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3706 Colin Walters writes: > Miles: You objected to putting special text properties on the buffer > text, and then fontifying on them later, correct? Unfortunately this > is the only way I can think of to implement fontification for special > buffers, such that typing M-x font-lock-mode will always do the Right > Thing. First of all, I think you're being overly aggressive about all this -- the status quo is _not a problem_. The mailing lists are not overflowing with bug reports about this issue, and I have yet to hear a single clamor. If we decide to adopt a generalized font-lock user interface, and it satisfies all the objections made, it really doesn't matter if some special modes take a while to be adapted to it. More consistency is usually a good thing, especially when it's easy to do, but there's really no need for immediate 100% coverage in this case. For special modes that add currently add face properties to directly the buffer, and which might have a hard time implementing an on-demand `font-lock-refontify-function' (perhaps they don't maintain enough context), why not just add a variable that tells the redisplay engine to ignore face properties for the buffer (it should probably keep paying attention to overlays)? That'd make the whole thing trivial in many cases. -Miles -- Would you like fries with that?