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 18:55:23 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <1020725723.5138.127.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> <1020662101.5288.76.camel@space-ghost> <87helleq50.fsf@tc-1-100.kawasaki.gol.ne.jp> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1020731658 28902 127.0.0.1 (7 May 2002 00:34:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 7 May 2002 00:34:18 +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 174svq-0007W3-00 for ; Tue, 07 May 2002 02:34:18 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 174t3E-0005RC-00 for ; Tue, 07 May 2002 02:41:56 +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 174svn-0001D7-00; Mon, 06 May 2002 20:34:15 -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 174rOo-0001vd-00 for ; Mon, 06 May 2002 18:56:06 -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 844BE7400252 for ; Mon, 6 May 2002 18:56:05 -0400 (EDT) Original-Received: by space-ghost.verbum.private (Postfix (Debian/GNU), from userid 1000) id C792F8C6C7B; Mon, 6 May 2002 18:55:23 -0400 (EDT) Original-To: emacs-devel@gnu.org In-Reply-To: <87helleq50.fsf@tc-1-100.kawasaki.gol.ne.jp> 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:3645 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:3645 On Mon, 2002-05-06 at 02:39, Miles Bader wrote: > For my part, I've never seen any complaints on any of the emacs > lists/newsgroups from people that dislike fontification in non-font-lock > modes (this is the important case, because most package currently seem > to either use font-lock, or if not, to default to always having > fontification). It is true that this does change the default; it removes fontification in an *Occur* buffer where there was fontification before. But in the end, the user gets more control, in a more consistent fashion, and I think this win outweighs the change of default. 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. > I think it is true that using font-lock is wasteful if all it does is > examine text-properties which could have just as easily been face > properties. It's only "wasteful" for those users who liked fontification in special modes like *Occur*, but not elsewhere. I really do think that those users are a relatively rare breed. 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.