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: Thu, 03 Aug 2006 11:12:37 -0400 Message-ID: References: <20060723142630.GB1433@muc.de> <20060731220419.GF1271@muc.de> <20060801092147.GB1176@muc.de> <20060801194800.GA1647@muc.de> <20060803084540.GA1282@muc.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1154618005 29736 80.91.229.2 (3 Aug 2006 15:13:25 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 3 Aug 2006 15:13:25 +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 Thu Aug 03 17:13:22 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 1G8esr-00037g-2W for ged-emacs-devel@m.gmane.org; Thu, 03 Aug 2006 17:13:13 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G8esq-0004Q5-D0 for ged-emacs-devel@m.gmane.org; Thu, 03 Aug 2006 11:13:12 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G8ese-0004Pa-TD for emacs-devel@gnu.org; Thu, 03 Aug 2006 11:13:00 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G8ese-0004PI-3m for emacs-devel@gnu.org; Thu, 03 Aug 2006 11:13:00 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G8esd-0004PF-Vl; Thu, 03 Aug 2006 11:13:00 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G8evq-0003tT-P1; Thu, 03 Aug 2006 11:16:18 -0400 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 98E622CEFA9; Thu, 3 Aug 2006 11:12:49 -0400 (EDT) Original-Received: from faina.iro.umontreal.ca (faina.iro.umontreal.ca [132.204.26.177]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 4B2BA445C; Thu, 3 Aug 2006 11:12:37 -0400 (EDT) Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 31FEF6C8CC; Thu, 3 Aug 2006 11:12:37 -0400 (EDT) Original-To: Alan Mackenzie In-Reply-To: <20060803084540.GA1282@muc.de> (Alan Mackenzie's message of "Thu, 3 Aug 2006 09:45:40 +0100") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca 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:58049 gmane.emacs.pretest.bugs:13274 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? > As opposed to using (c-font-lock-expand-region BEG END OLD-LEN) called > from \(font-lock\|jit-lock\)-after-change, and also (as we thrashed out > some while ago) from font-lock-default-fontify-region. Let's say your identification function (called from f-l-d-fontify-region) is named c-font-lock-expand-region. Then calling this function from f-l-after-change won't do you much good because: - you've already solved the problem of identification (and f-l-after-change is not a place where you can solve the problem of identification anyway). - the problem of rehighlighting (which amounts to figuring out which part of the buffer *used to be* a multiline element) needs to look at the buffer *before* the change, not after. > Stefan, was that question of yours really needed? Yes, the details matter, and it was very much unclear to me what were your assumptions. >> 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. > The f-l-multiline mechanism forces a distinction between the first > fontification and subsequent fontifications, a distinction which didn't > previously exist. This is surely a Bad Thing, suggesting that f-l-m is > suboptimal. Actually, the distinction has always been present: it's the distinction between highlighting and dehighlighting. >> > 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). > I think your logic is flawed there. Certainly calculations will need > doing in before-change-functions, for the reason you give. Well, no, not really: Actually, the calculations can happen at any time between the highlighting and before-change-function. With font-lock-multiline, the "calculation" is done while highlighting (because at this point you already have the info necessary so no extra real calculation is needed). Then this info is saved (in the form of the font-lock-multiline text-property) to be used after the change. > But it is not clear that MORE calculation has to be done, rather that it > has to be done in a different place. Maybe you're right. In my experience, adding the font-lock-multiline property while highlighting has *never* required any significant extra calculations. The examples I've shown (in cc-awk.el and cc-fonts.el) have been pretty typical in this respect. >> >> > 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 mean the function that will be called with parameters BEG, END, and > OLD-LEN from \(font\|jit\)-after-change-function, and also the same (or a > similar) function that will need to be called from > font-lock-fontify-region, as you pointed out back in ?April. As mentioned above, I can't see how those two functions could be the same (or similar) and yet both be useful. > So a font-lock-extend-region-function is needed for a buffer's very first > fontification. Do you agree? Yes. It's now even in Emacs-CVS under the name font-lock-extend-region-functions. > This function could determine the region for future fontifications > equally well, too. Yes, it could be used in a before-change-function as well. > So it would seem that applying font-lock-multiline properties is > redundant - UNLESS doing so has some other benefit, such as reducing the > amount of computation. Indeed. [ Modulo the fact that if you don't have an identification function, you may still be able to use the font-lock-multiline property to properly handle those multiline elements which you happen to identify somehow. ] > I think you're assuming that recalculating f-l-m properties can be done as > a cheap side effect of applying faces. Yes. > I'm not at all sure this is the case. This has been my experience in every single case. And I think it's no coincidence. Stefan