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.devel Subject: Re: [sigra@home.se: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows] Date: Thu, 16 Feb 2006 11:10:48 +0000 (GMT) Message-ID: References: <43F35997.7080007@gmx.at> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: sea.gmane.org 1140089321 31979 80.91.229.2 (16 Feb 2006 11:28:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 16 Feb 2006 11:28:41 +0000 (UTC) Cc: Ralf Angeli , bug-cc-mode@gnu.org, Stefan Monnier , rms@gnu.org, emacs-devel@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Thu Feb 16 12:28:33 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 1F9hJI-0000bM-39 for sf-cc-mode-help@m.gmane.org; Thu, 16 Feb 2006 12:28:32 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam2.sourceforge.net (Postfix) with ESMTP id 8733D129BA; Thu, 16 Feb 2006 03:28:10 -0800 (PST) Original-Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1F9hIU-0002Wf-Jg for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 03:27:42 -0800 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by mail.sourceforge.net with esmtps (TLSv1:RC4-SHA:128) (Exim 4.44) id 1F9hIU-0001xa-6R for cc-mode-help@lists.sourceforge.net; Thu, 16 Feb 2006 03:27:42 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1F9hIQ-0005kC-Rf for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 06:27:39 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1F9hNV-0004E5-2J for bug-cc-mode@gnu.org; Thu, 16 Feb 2006 06:32:56 -0500 Original-Received: from [193.149.49.134] (helo=acm.acm) by monty-python.gnu.org with esmtp (Exim 4.52) id 1F9hNO-0004DC-F7; Thu, 16 Feb 2006 06:32:49 -0500 Original-Received: from localhost (root@localhost) by acm.acm (8.8.8/8.8.8) with SMTP id LAA00424; Thu, 16 Feb 2006 11:10:48 GMT X-Sender: root@acm.acm Original-To: martin rudalics In-Reply-To: <43F35997.7080007@gmx.at> 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 Original-Sender: cc-mode-help-admin@lists.sourceforge.net Errors-To: cc-mode-help-admin@lists.sourceforge.net X-BeenThere: cc-mode-help@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: , List-Id: Bug reports, feature requests, and general talk about CC Mode. List-Post: List-Help: List-Subscribe: , List-Archive: X-Original-Date: Thu, 16 Feb 2006 11:10:48 +0000 (GMT) Xref: news.gmane.org gmane.emacs.cc-mode.general:3025 gmane.emacs.devel:50608 Archived-At: Hi, Martin! On Wed, 15 Feb 2006, martin rudalics wrote: > > That's how I understand it. The region to be fontified will get > > extended backwards to the starting tag regardless of this point being > > visible in the window or not. If it will be fontified right away or > > marked to be fontified by jit-lock depends upon either > > `jit-lock-after-change' or `font-lock-after-change-function' being > > present in `after-change-functions'. >Presumably the "region to be fontified gets extended" by resetting its >fontified text-property to nil. `jit-lock-after-change' should be able >to do this if you provide the correct start and end values. But keep in >mind that with jit-lock redisplay immediately triggers refontification >of displayed text whose fontified text-property has been reset to nil. >This refontification won't recognize any "starting tag" preceding >window-start unless you explicitly tell it to go there, for example, by >using a multiline property. If you decide on the `font-lock-multiline' >property, every time you insert or delete a character nearby, redisplay >has to refontify the entire contiguous area covered by the property. There's a fundamental mismatch between Font Lock's implementation and reality: Font Lock assumes that, with the exception of comments and strings, the fontification of a region is dependent only on text near the region. This works pretty well for programming languages, but badly for mark-up languages. Conceptually, Emacs partitions the problem into a low-intensity global task (locating comments and strings), for which it has the fast syntax routines, and a high-intensity local task (hairy syntax analysis near point.) It is worth noting that the syntax routines support 2-character delimiters (like "/*"), if only by kludge. I am convinced that, in the long term, we need an analogous, fast, global mechanism for for locating and characterizing regions bounded by arbitrary delimiters - in this case "<<" and ">>", but could just as well be Texinfo's "{" and "}" or Lex's and Yacc's "%{", "%}" and "%%" or "literate programing"'s boundaries between narrative text and executable code, or "here documents" within a shell script. Until we have this, I think we'll be entangling ourselves in an ever stickier web of ad-hoc workarounds. -- Alan. ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642