From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Colin Walters Newsgroups: gmane.emacs.devel Subject: Re: kill ring menu Date: 06 May 2002 01:15:01 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <1020662101.5288.76.camel@space-ghost> 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> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1020666209 10953 127.0.0.1 (6 May 2002 06:23:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 6 May 2002 06:23:29 +0000 (UTC) Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 174buD-0002qX-00 for ; Mon, 06 May 2002 08:23:29 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 174c1E-0005ul-00 for ; Mon, 06 May 2002 08:30:44 +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 174bCN-0005MX-00; Mon, 06 May 2002 01:38:11 -0400 Original-Received: from monk.debian.net ([216.185.54.61] helo=monk.verbum.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 174avV-0003mG-00 for ; Mon, 06 May 2002 01:20:45 -0400 Original-Received: from space-ghost.verbum.private (freedom.cis.ohio-state.edu [164.107.60.183]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "space-ghost.verbum.org", Issuer "monk.verbum.org" (verified OK)) by monk.verbum.org (Postfix (Debian/GNU)) with ESMTP id 2D3067400252 for ; Mon, 6 May 2002 01:20:34 -0400 (EDT) Original-Received: by space-ghost.verbum.private (Postfix (Debian/GNU), from userid 1000) id 016CC8B92FA; Mon, 6 May 2002 01:15:01 -0400 (EDT) Original-To: emacs-devel@gnu.org In-Reply-To: <200205051746.g45Hk5P01808@aztec.santafe.edu> X-Mailer: Ximian Evolution 1.0.3 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:3620 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3620 Since we're apparently moving this discussion to emacs-devel, I'll give some context: One of the things Richard commented on was how my proposed browse-kill-ring patch used font-lock for fontification. He suggested to apply the faces when the buffer was constructed, and that using font-lock was wasteful. However, I think there is a more general and useful paradigm for fontification in special modes. What I do in that patch (and also in ibuffer and the new occur-mode) is to apply a special text property (say 'occur-match) to areas of text, and then set up a `font-lock-fontify-region-function' which then searches for those text properties and applies faces. If the user never turns on font-lock-mode, then no fontification will occur, and font-lock.el will never be loaded. If they do, then things will automagically be fontified. For example, in the new Occur implementation, you can switch to the *Occur* buffer and type 'M-x font-lock-mode' to toggle fontification on and off, and it will Just Work. The same is true for ibuffer. On Sun, 2002-05-05 at 13:46, Richard Stallman wrote: > That might be a valid point. It raises the question: whether it is > better, in these modes that construct special text and can highlight > it, to enable its highlighting by default, or to make it controllable > with M-x font-lock-mode. Well, these are two separate issues. If we make things controllable via M-x font-lock-mode, then the user can choose whether or not to enable highlighting by default through the usual font-lock mechanisms, such as the functions `global-font-lock-mode', and `font-lock-mode', as well as the variable `font-lock-global-modes', etc. > In the past we've acted on the view that it is better to highlight > these buffers by default, and the expectation that a considerable > fraction of users won't use Font-Lock mode but will benefit from > highlighting these special buffers. I assert (without any statistics) that the vast majority of users put (global-font-lock-mode 1) in their ~/.emacs file (thereby loading font-lock.el), and expect fontification in every mode, while the remaining portion don't want any fontification at all. So in almost all cases, there is no waste, because font-lock.el will already be loaded, or will be used by other modes.