From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.pretest.bugs,gmane.emacs.devel Subject: Re: [simon.marshall@misys.com: Font Lock on-the-fly misfontification in C++] Date: Tue, 1 Aug 2006 20:48:00 +0100 Message-ID: <20060801194800.GA1647@muc.de> References: <20060723142630.GB1433@muc.de> <20060731220419.GF1271@muc.de> <20060801092147.GB1176@muc.de> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1154457969 27854 80.91.229.2 (1 Aug 2006 18:46:09 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 Aug 2006 18:46:09 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-pretest-bug@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Tue Aug 01 20:46:05 2006 Return-path: Envelope-to: gebp-emacs-pretest-bug@gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G7zFe-00050Z-5w for gebp-emacs-pretest-bug@gmane.org; Tue, 01 Aug 2006 20:45:59 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7zFd-0005uH-E8 for gebp-emacs-pretest-bug@gmane.org; Tue, 01 Aug 2006 14:45:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G7zFX-0005sP-Gg for emacs-pretest-bug@gnu.org; Tue, 01 Aug 2006 14:45:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G7zFX-0005s7-0b for emacs-pretest-bug@gnu.org; Tue, 01 Aug 2006 14:45:51 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G7zFW-0005s3-QN for emacs-pretest-bug@gnu.org; Tue, 01 Aug 2006 14:45:50 -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 1G7zIT-0002HU-26 for emacs-pretest-bug@gnu.org; Tue, 01 Aug 2006 14:48:53 -0400 Original-Received: (qmail 88927 invoked from network); 1 Aug 2006 18:45:45 -0000 Original-Received: from acm.muc.de (HELO localhost.localdomain) (Debian-exim@193.149.49.134) by mail.muc.de with SMTP; 1 Aug 2006 18:45:45 -0000 Original-Received: from acm by localhost.localdomain with local (Exim 4.50) id 1G80Dg-0001sw-Bp; Tue, 01 Aug 2006 20:48:00 +0100 Original-To: Stefan Monnier Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-BeenThere: emacs-pretest-bug@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for CVS Emacs." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Errors-To: emacs-pretest-bug-bounces+gebp-emacs-pretest-bug=gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.pretest.bugs:13247 gmane.emacs.devel:57954 Archived-At: 'Evening, Stefan! On Tue, Aug 01, 2006 at 10:55:41AM -0400, Stefan Monnier wrote: > > As a matter of interest, does the f-l-multiline mechanism somehow > > work with a _first_ fontification? Assume CC Mode has been enhanced > > to use f-l-multiline. Say we have a buffer of C source in > > fundamental mode (so there're no f-l-m properties on the buffer), and > > the top of the screen is in the middle of a C construct. If we do > > M-x c-mode, will the top line get correctly fontified? > No, as explained in the lispref manual, to handle multiline elements, > you have to handle both /rehighlighting/ (e.g. Simon's problem that > started this thread) and /identification/ (e.g. what you describe here) > and although the two are closely related, they cannot be handled in the > same way. 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? It's going to be more code. Might it, for example, be faster? > The f-l-multiline property allows you to handle /rehighlighting/ but > not /identification/. > > 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. > > I don't agree here; a bug report from Peter Dyballa (back in February or > > March) gave this as an example: > >> /* lots of things don't have */ > >> /* A/UX systems include it from stdlib, from Xos.h */ > >> #ifndef VMS /* VMS hates multi-line '#if's */ > >> # if !defined(ibm032) && \ > >> !defined(__convex__) && \ > >> !(defined(vax) && !defined(ultrix)) && \ > >> !defined(mips) && \ > >> !defined(apollo) && \ > >> !defined(pyr) && \ > >> !defined(__UMAXV__) && \ > >> !defined(bsd43) && \ > >> !defined(__bsd43) && \ > >> !(defined(BSD) && (BSD >= 199103)) && \ > >> !defined(aux) && \ > >> !defined(__bsdi__) && \ > >> !defined(sequent) > >> As the attached picture shows some "defined" keywords are not > >> emphasised: > I don't know whether the bug was that the `defined' keywords were not > originally correctly fontified (problem of /identification/), or whether > their correct highlighting was preserved when editing the text (problem of > /rehighlighting/). If it's the former, then it's unrelated to what I'm > talking about. 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. 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. > > There is nothing in the functions currently in cc-fonts capable of > > locating the opening "# if" when one of the subsequent lines is > > changed. > If the original highlighting was correct, then when you did this > original highlighting you happened to know where the "# if" was located > (even though you don't have any code that can find it in the general > case) and you could have remembered that info by placing a > font-lock-multiline property. In the above example, the file has merely been loaded with C-x C-f. I suspect that the fontification goes awry where the display code splits the buffer into ~500 byte chunks. > Stefan -- Alan.