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: 07 May 2002 10:35:49 +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> 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 1020735551 1728 127.0.0.1 (7 May 2002 01:39:11 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 7 May 2002 01:39:11 +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 174twb-0000Rk-00 for ; Tue, 07 May 2002 03:39:09 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 174u40-0006sU-00 for ; Tue, 07 May 2002 03:46:48 +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 174twY-0005Qj-00; Mon, 06 May 2002 21:39:06 -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 174tup-0005HB-00; Mon, 06 May 2002 21:37:19 -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 g471bAR15192; Tue, 7 May 2002 10:37:10 +0900 (JST) Original-Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g471b6R01593; Tue, 7 May 2002 10:37:06 +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 g471Zor14547; Tue, 7 May 2002 10:37:00 +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 g471ZoK11620; Tue, 7 May 2002 10:35:50 +0900 (JST) Original-Received: by mcspd15.ucom.lsi.nec.co.jp (Postfix, from userid 31295) id 43BBC3723; Tue, 7 May 2002 10:35:50 +0900 (JST) Original-To: Colin Walters System-Type: i686-pc-linux-gnu Blat: Foop In-Reply-To: <1020725723.5138.127.camel@space-ghost> Original-Lines: 38 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:3648 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3648 Colin Walters writes: > And finally, this is a situation where we have a user-interface win > (consistency of interface to enabling/disabling fontification) over > resource consumption (loading of font-lock.el). I think that as a > general principle, the former should win over the latter. You're assuming such `consistency' is a win. Usually consistency is, but several people have said on this thread that they _like_ the current `inconsistency.' The rules people follow are not always as simple as you might wish. Perhaps in this case people see a distinction between fontifying existing `text files' (like program source) and buffers that are created by emacs to display some information. In any case, if it's _really_ desirable to have the single concept of font-locking control all fontification in buffers (and obviously this is not clear), then it still seems a bit silly to have font-lock following non-face properties in the buffer; you could just as easily arrange for the font-lock `user interface' (e.g., toggling font-lock mode) to be separate from the font-lock `mechanism' (the part that adds face properties), and have whatever ad-hoc fontification code you wish follow the dictates of the former without using the latter. > Using font-lock from the start is a win for other reasons, too. Suppose > that Occur mode was changed so you could actually edit the buffer, and > changes would be reflected in the original buffer. If the user typed > additional matches for the search string into the *Occur* buffer, we > would expect them to be made bold, too. This is possible in a clean way > if we use a dynamic font-lock mechanism. This is only true if you use `real' font-locking -- e.g., regexps that match the buffer text -- instead of making font-lock follow text properties to do its locking. You could have _both_ of course, but that seems silly; if you really want to dynamically update user added text, you may as well just use traditional font-locking from the start. -Miles -- Fast, small, soon; pick any 2.