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: Tue, 1 Aug 2006 10:21:47 +0100 Message-ID: <20060801092147.GB1176@muc.de> References: <20060723142630.GB1433@muc.de> <20060731220419.GF1271@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 1154420406 26954 80.91.229.2 (1 Aug 2006 08:20:06 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 1 Aug 2006 08:20:06 +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 Tue Aug 01 10:20:04 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 1G7pTk-0003Eo-E1 for sf-cc-mode-help@m.gmane.org; Tue, 01 Aug 2006 10:19:53 +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 AA51912D1D; Tue, 1 Aug 2006 01:19:51 -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 1G7pTi-0002si-6K for cc-mode-help@lists.sourceforge.net; Tue, 01 Aug 2006 01:19:50 -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 1G7pTh-0007vX-J7 for cc-mode-help@lists.sourceforge.net; Tue, 01 Aug 2006 01:19:50 -0700 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1G7pTf-0008NC-8k for bug-cc-mode@gnu.org; Tue, 01 Aug 2006 04:19:47 -0400 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1G7pWV-0004Oe-OL for bug-cc-mode@gnu.org; Tue, 01 Aug 2006 04:22:43 -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 1G7pWU-0004OM-RA for bug-cc-mode@gnu.org; Tue, 01 Aug 2006 04:22:43 -0400 Original-Received: (qmail 30673 invoked from network); 1 Aug 2006 08:19:43 -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 08:19:43 -0000 Original-Received: from acm by localhost.localdomain with local (Exim 4.50) id 1G7qRf-0000j5-Nb; Tue, 01 Aug 2006 10:21:47 +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:3677 gmane.emacs.pretest.bugs:13239 gmane.emacs.devel:57924 Archived-At: Morning, Stefan! On Mon, Jul 31, 2006 at 06:03:41PM -0400, Stefan Monnier wrote: > >> The patch below seems to fix number 2 and 3 for me. Someone who > >> understands cc-fonts.el better than me and thus knows where the two > >> "public XXX" lines are handled could probably do a similar > >> adjustment for them. > > At the very least, this isn't suitable for the CC Mode repository, > > since font-lock-multiline hasn't (yet?) been implemented in XEmacs > > or older GNU Emacsen. > I find it quite suitable, personally, since although it indeed only > fixes the OP's problem under Emacs-22 (and Emacs-21 if you're willing > to set the font-lock-multiline variable to t), it won't hurt in > Emacs-20 or XEmacs. > Better yet: you can make it work under any old font-lock > implementation (Emacs-19/20/21, XEmacs-??) by using > font-lock-fontify-region-function to obey the font-lock-multiline > property. And yes, f-l-fontify-region-function does exist in XEmacs. :-) 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? > > I don't know cc-fonts.el that well myself, yet, but I get the > > feeling that putting in f-l-multiline properties like this is, at > > best, only going to converge gradually on a working solution [to the > > problem of CC Mode lines being fontified out of context]. How will > > we know when every case has been covered? > - Check every place where you set faces > - see on which part of the buffer's text this highlighting decision > depends > - add a f-l-multiline property on it if it spans more than a line (or > even: add a f-l-multiline property on it no matter what if you > prefer it that way). > If you've indeed checked every place where a highlighting is added, > then you know you've covered all cases. 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 ; > > As I've said once or twice before, I'd prefer to calculate the f-l > > change region explicitly at each change. > I have a hard time imagining how that's going to be very different: > you'll have to check every possible situation to figure out which > region to use. :-) You're probably right there, too! Actually, the convergence would be from a different direction: I'd start using (I think) c-beginning-of-statement-1, which would be reliable but unbearably sluggish, then optimise the sluggishness away with caching mechanisms and whatnot. > How will you know that you indeed haven't missed one possible case? > Since the cases you care about are those handled by your highlighting > code, I'd expect it's easier to make sure you've covered all cases if > you add the code directly where you handle each case. 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: There is nothing in the functions currently in cc-fonts capable of locating the opening "# if" when one of the subsequent lines is changed. I think I'd need to put a `c-beginning-of-statement-1' thing in the bit of code which would apply f-l-multiline. I think I'd need to call that function lots of times, in each fontification routine. I think that's because we have very different conceptual models of code. I think that having f-l-multiline code throughout the existing cc-fonts.el would be more difficult to test (and much easier to forget about when making other changes) than having a distinct function c-beginning-of-font-lock-region. > Stefan -- 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