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: new text property Date: 10 Jun 2002 01:46:22 -0400 Sender: emacs-devel-admin@gnu.org Message-ID: <1023687982.1593.1326.camel@space-ghost> References: <1023607376.8184.1228.camel@space-ghost> <87y9dnycw8.fsf@tleepslib.sk.tsukuba.ac.jp> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1023688326 15521 127.0.0.1 (10 Jun 2002 05:52:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 10 Jun 2002 05:52:06 +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 17HI62-00042E-00 for ; Mon, 10 Jun 2002 07:52:06 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17HISi-000770-00 for ; Mon, 10 Jun 2002 08:15:33 +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 17HI5X-0004Iz-00; Mon, 10 Jun 2002 01:51:35 -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 17HI4h-0004Ef-00 for ; Mon, 10 Jun 2002 01:50:43 -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 5DE0374000BA; Mon, 10 Jun 2002 01:50:32 -0400 (EDT) Original-Received: by space-ghost.verbum.private (Postfix (Debian/GNU), from userid 1000) id 635E28AD820; Mon, 10 Jun 2002 01:46:22 -0400 (EDT) Original-To: emacs-devel@gnu.org, xemacs-design@xemacs.org In-Reply-To: <87y9dnycw8.fsf@tleepslib.sk.tsukuba.ac.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:4681 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4681 On Mon, 2002-06-10 at 00:29, Stephen J. Turnbull wrote: > Er, as I understood that thread, the rationale is that font-lock is > too heavy (aka "slow and broken") to be used by modes that just want > some "light-weight" highlighting. Is that not so? Are there other > advantages to not using font-lock to do font-locking? The font-lock you are thinking of is regexp and search-based fontification, both of which can be slow (and in the case of regexps quite often broken). But typing 'M-x font-lock-mode' is a nice *interface* to enabling and disabling fontification. It doesn't mean the mode has to use regexp or search-based fontification. In Emacs we now have "font-core.el", which just defines the bare bones of `font-lock-mode' and `global-font-lock-mode'. It allows a mode (like `occur') which uses the new `font-lock-face' to allow its fontification to be toggled via M-x font-lock-mode, without loading all of the regexp and other machinery of font-lock.el. > I think we should look into allowing all highlighting to be done by > font-lock by making font-lock performance better. The performance of `font-lock-face' in Emacs is essentially equivalent to that of the `face' property; i.e. it is not an issue. I suspect you could easily achieve the same results in XEmacs.