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: Mon, 24 Jul 2006 16:43:14 -0400 Message-ID: References: <20060723142630.GB1433@muc.de> <20060724133343.GA1111@muc.de> <20060724192940.GC1111@muc.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1153773940 16133 80.91.229.2 (24 Jul 2006 20:45:40 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Jul 2006 20:45:40 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-pretest-bug@gnu.org, "Marshall, Simon" , Richard Stallman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 24 22:45:36 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 1G57HL-0005VW-To for ged-emacs-devel@m.gmane.org; Mon, 24 Jul 2006 22:43:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G57HL-0007Wf-83 for ged-emacs-devel@m.gmane.org; Mon, 24 Jul 2006 16:43:51 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G57Gx-0007Et-IR for emacs-devel@gnu.org; Mon, 24 Jul 2006 16:43:27 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G57Gw-0007Do-Iz for emacs-devel@gnu.org; Mon, 24 Jul 2006 16:43:27 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G57Gw-0007Dd-Fb; Mon, 24 Jul 2006 16:43:26 -0400 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G57I4-0005U8-I9; Mon, 24 Jul 2006 16:44:36 -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 8A0CC2CEB78; Mon, 24 Jul 2006 16:43:23 -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 BF2E7445C; Mon, 24 Jul 2006 16:43:14 -0400 (EDT) Original-Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 770976C9DD; Mon, 24 Jul 2006 16:43:14 -0400 (EDT) Original-To: Alan Mackenzie In-Reply-To: <20060724192940.GC1111@muc.de> (Alan Mackenzie's message of "Mon, 24 Jul 2006 20:29: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:57571 gmane.emacs.pretest.bugs:13118 Archived-At: > Date: Sun, 30 Apr 2006 12:48:36 +0000 (GMT) > From: Alan Mackenzie > Reply-To: Alan Mackenzie > To: emacs-devel@gnu.org > Subject: font-lock-extend-region-function: Final refinements. > It hasn't as yet been installed, although it would establish the > infrastructure with which the problems being discussed here could be > wholly and efficiently erradicated, without resort to obscure coding. Richard put it on the backburner, claiming he hasn't seen the other thread where you presented your point of view and then I presented mine. We need to start it over, but I've had other horses to flog. > I know what your paragraph refers to. We've discussed it at great > length already, and I think I understood it at the time you posted it. > That approach is more obscure and more inefficient (in terms of > processor cycles) than anything I want to put into CC Mode. You haven't shown any evidence of inefficiency. > Is there any chance of you adapting the font-lock-multiline mechanism so > that the properties can be applied _before_ fontification, exactly where > they are needed, rather than _after_ fontification throughout the entire > change region? That's the thing on the backburner. But it's still unrelated to the OP's problem which was specifically about *re*fontification, where the current font-lock-multiline support is all you need (and if you don't like it, there are already several existing alternatives, see the lispref manual). I.e. you need both to be able to extend the region just-before fontification (to do the initial discovery of multi-line elements) and to re-extend the region based on info kept from the last fontification (to properly refontify such elements). >> > I also dislike being unable to specify an exact fontification region >> > to Font Lock (such as the bounds of one of Simon's comments). >> I don't understand what you're referring to. >> From Simon's example: > public Bar // Bar fontified as a type, at first > type a space after "first". The region I want to specify to Font Lock > is exactly this: > public Bar // Bar fontified as a type, at first > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Oh, I see. It seems very minor. Why do you care? Is the performance difference ever noticeable? If yes, how often? > Most of CC Mode's languages are not line-based. Same as 99% of the languages supported by Emacs. > I think it's unhelpful to construe it's font-locking stuff in terms of > buffer lines. This is what has led to many complaints about font locking > in CC Mode (many of which have appeared directly in bug-cc-mode). If CC > Mode can specify a font-locking region based on language constructs > (e.g. a whole statement, a comment, a string, a declaration), these > problems will go away. Thanks to CPP and other preprocessors, there will always be cases you can't handle. > Even entries to the obfuscated C competition would > get correctly and efficiently fontified. I don't see why we should waste our time trying to handle that correctly. Stefan