From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.pretest.bugs Subject: Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++] Date: Tue, 01 Aug 2006 15:23:54 -0400 Message-ID: References: <20060723142630.GB1433@muc.de> <20060731220419.GF1271@muc.de> <20060801092147.GB1176@muc.de> <20060801194800.GA1647@muc.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1154460320 3433 80.91.229.2 (1 Aug 2006 19:25:20 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 Aug 2006 19:25:20 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-pretest-bug@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 01 21:25:17 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G7zqf-0004fe-1Y for ged-emacs-devel@m.gmane.org; Tue, 01 Aug 2006 21:24:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7zqe-0008HI-Mx for ged-emacs-devel@m.gmane.org; Tue, 01 Aug 2006 15:24:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7zqQ-0008Ap-Ne for emacs-devel@gnu.org; Tue, 01 Aug 2006 15:23:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7zqO-00086N-Vh for emacs-devel@gnu.org; Tue, 01 Aug 2006 15:23:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7zqO-00086I-S4; Tue, 01 Aug 2006 15:23:56 -0400 Original-Received: from [209.226.175.34] (helo=tomts13-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G7ztK-0005xe-HZ; Tue, 01 Aug 2006 15:26:58 -0400 Original-Received: from localhost ([70.55.146.253]) by tomts13-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060801192354.FVYC29052.tomts13-srv.bellnexxia.net@localhost>; Tue, 1 Aug 2006 15:23:54 -0400 Original-Received: by localhost (Postfix, from userid 20848) id 362336B1D9; Tue, 1 Aug 2006 15:23:54 -0400 (EDT) Original-To: Alan Mackenzie In-Reply-To: <20060801194800.GA1647@muc.de> (Alan Mackenzie's message of "Tue, 1 Aug 2006 20:48:00 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:57956 gmane.emacs.pretest.bugs:13249 Archived-At: > It seems that the identification of the "safe place" (in a previously > unfontified region) needs to be done by a function essentially the same > as font-lock-extend-region-function, since f-l-multiline properties > haven't yet been applied. In that case, what is the advantage in using > f-l-multiline at all? As opposed to using what? Remember f-l-multiline is about /rehighlighting/. Think of it as *de*highlighting. I.e. find the places where there used to be a multiline element but not any more. > It's going to be more code. Might it, for > example, be faster? It's expected to be faster than recomputing this extended region in before-change-function (since it's the only place where you can do it otherwise: in after-change-function it's too late (unless you saved the info somewhere) because the buffer text may not contain the pertinent info). >> > Maybe you're right here. But care would be needed to ensure that >> > there is some boundary between adjacent f-l-multiline regions, such >> > as in this sort of thing: >> > foo = >> > 3 ;bar = >> > /* ^^ */ >> > 4 ; >> Yes, that's a problem. I don't even think the current code handles it >> right. > Again, this problem doesn't happen with the f-l-extend-region-function > approach. [ Not sure what you mean by f-l-extend-region-function, BTW. Is it the current f-l-extend-region-function in Emacs-CVS, or is it some future thingy that will be called from f-l-refontify-region? The current f-l-extend-region-function can't help with /identification/ any more than f-l-multiline. ] I expect that the difference is not in the approaches but in their particular implementation at a particular moment in time. > When you load that file (having stripped the leading "> >>" from each > line ;-), only the first 8 "defined"s get fontified. (Up to byte 500 > (jit-lock-chunk-size), perhaps?) If you set font-lock-support-mode to > nil, the whole caboodle is (at least to begin with) fontified right. I.e. it's a problem of /identification/, so of course f-l-multiline won't help you. > The point I was trying to make was that locating the "safe place" can be > a long-winded slow operation - that in a piece of code like the above > (which isn't untypical), the strategy of placing f-l-multiline properties > might cause this expensive analysis to be done several times per buffer > change. I don't understand: the costly operation to find the safe place is what you need for /identification/. Once you've done that, the f-l-multiline property allows you to store the resulting info (which you computed for /identification/, not for f-l-multiline) so you won't have to recompute it later when deciding what to dehighlight. Stefan