From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.pretest.bugs,gmane.emacs.devel Subject: Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++] Date: Thu, 3 Aug 2006 09:45:40 +0100 Message-ID: <20060803084540.GA1282@muc.de> 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" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1154591049 4796 80.91.229.2 (3 Aug 2006 07:44:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 3 Aug 2006 07:44:09 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-pretest-bug@gnu.org, emacs-devel@gnu.org Original-X-From: cc-mode-help-bounces@lists.sourceforge.net Thu Aug 03 09:44:02 2006 Return-path: Envelope-to: sf-cc-mode-help@m.gmane.org Original-Received: from lists-outbound.sourceforge.net ([66.35.250.225]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G8Xs5-0007SM-Ff for sf-cc-mode-help@m.gmane.org; Thu, 03 Aug 2006 09:43:57 +0200 Original-Received: from sc8-sf-list1-new.sourceforge.net (unknown [10.3.1.93]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 6925FFE67; Thu, 3 Aug 2006 00:43:56 -0700 (PDT) Original-Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1-new.sourceforge.net with esmtp (Exim 4.43) id 1G8Xs2-00021M-A3 for cc-mode-help@lists.sourceforge.net; Thu, 03 Aug 2006 00:43:54 -0700 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by mail.sourceforge.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.44) id 1G8Xry-0003v7-PB for cc-mode-help@lists.sourceforge.net; Thu, 03 Aug 2006 00:43:54 -0700 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1G8Xrp-0005Du-DN for bug-cc-mode@gnu.org; Thu, 03 Aug 2006 03:43:41 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1G8Xv1-0001f1-M6 for bug-cc-mode@gnu.org; Thu, 03 Aug 2006 03:47:01 -0400 Original-Received: from [193.149.48.1] (helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G8Xv0-0001du-O3 for bug-cc-mode@gnu.org; Thu, 03 Aug 2006 03:46:59 -0400 Original-Received: (qmail 55044 invoked from network); 3 Aug 2006 07:43:20 -0000 Original-Received: from acm.muc.de (HELO localhost.localdomain) (Debian-exim@193.149.49.134) by mail.muc.de with SMTP; 3 Aug 2006 07:43:20 -0000 Original-Received: from acm by localhost.localdomain with local (Exim 4.50) id 1G8Ypo-0000cN-Us; Thu, 03 Aug 2006 09:45:41 +0100 Original-To: Stefan Monnier Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on monty-python X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=failed version=3.0.4 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by sourceforge.net. See http://spamassassin.org/tag/ for more details. Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001 1.0 FORGED_RCVD_HELO Received: contains a forged HELO X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.1.8 Precedence: list List-Id: "Bug reports, feature requests, and general talk about CC Mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: cc-mode-help-bounces@lists.sourceforge.net Errors-To: cc-mode-help-bounces@lists.sourceforge.net Xref: news.gmane.org gmane.emacs.cc-mode.general:3698 gmane.emacs.pretest.bugs:13270 gmane.emacs.devel:58036 Archived-At: Morning, Stefan! On Tue, Aug 01, 2006 at 03:23:54PM -0400, Stefan Monnier wrote: > > 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. Stefan, was that question of yours really needed? After the substantial amount of discussion we've had over the issue in the last few months, was it not clear exactly what I meant? I've been feeling frustrated at your posts on this topic for a long time, in that you don't seem to be carrying the context of one post forward to the next. This means I've got to keep restating the basis of the discussion time after time and this makes constructive dialog very wearisome. > 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. > > 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. 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 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. [ .... ] > > 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. So a font-lock-extend-region-function is needed for a buffer's very first fontification. Do you agree? This function could determine the region for future fontifications equally well, too. 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. > > 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. In the current f-l-m approach, the f-l-m properties are erased and recalculated after every fontification: the _identification_ is done repeatedly. (Is there any fundamental reason for this? Would it not be possible and better to allow the major mode code to decide when to recalculate them?) I think you're assuming that recalculating f-l-m properties can be done as a cheap side effect of applying faces. I'm not at all sure this is the case. -- Alan. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV