From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: 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: Tue, 14 Mar 2006 17:11:59 -0500 Message-ID: <87d5go7kef.fsf-monnier+emacs@gnu.org> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1142374351 1136 80.91.229.2 (14 Mar 2006 22:12:31 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 14 Mar 2006 22:12:31 +0000 (UTC) Cc: bug-cc-mode@gnu.org, martin rudalics , Ralf Angeli , "Richard M. Stallman" , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 14 23:12:29 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 1FJHkc-0006x9-Ie for ged-emacs-devel@m.gmane.org; Tue, 14 Mar 2006 23:12:22 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FJHkc-00074r-1B for ged-emacs-devel@m.gmane.org; Tue, 14 Mar 2006 17:12:22 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FJHkR-00074m-PU for emacs-devel@gnu.org; Tue, 14 Mar 2006 17:12:11 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FJHkQ-00074a-Sr for emacs-devel@gnu.org; Tue, 14 Mar 2006 17:12:11 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FJHkQ-00074X-Q3 for emacs-devel@gnu.org; Tue, 14 Mar 2006 17:12:10 -0500 Original-Received: from [209.226.175.97] (helo=tomts40-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FJHob-0003RK-7W; Tue, 14 Mar 2006 17:16:29 -0500 Original-Received: from alfajor ([67.71.115.9]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060314221159.XNEJ21861.tomts40-srv.bellnexxia.net@alfajor>; Tue, 14 Mar 2006 17:11:59 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id 9C67ED73A1; Tue, 14 Mar 2006 17:11:59 -0500 (EST) Original-To: Alan Mackenzie In-Reply-To: (Alan Mackenzie's message of "Tue, 14 Mar 2006 19:23:22 +0000 (GMT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) 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:51631 Archived-At: >> Here's the change I was talking about. Would someone please adapt >> this _now_ to the current sources, and install it? Then please rename >> before-font-lock-after-change-function to >> font-lock-extend-region-function, and rename >> font-lock-run-before-after-change-hook to font-lock-extend-region? >> Then please ack this message. > DONE. In the process, I moved the processing of font-lock-lines-before > from font-lock-default-fontify-region into > font-lock-after-change-function and jit-lock-after-change, so as to be > able to stop them interfering with eachother. As discussed and agreed in this list, font-lock-lines-before should simply be removed since it is subsumed by the new feature. Also, I thought we had agreed that this new feature should be in f-l-default-fontify-region rather than f-l-after-change-function. I believe it is *wrong* for it to be in f-l-after-change-function where it is mostly useless: you can already get the same result by using an (non-f-l)after-change-functions hook that sets the font-lock-multiline property. > More controversially, I've explicitly documented that the region returned > by the f-l-extend-region may start or end in the middle of a line. I don't care much either way. If someone does that, it's his problem: it won't hurt font-lock.el. But it may screw up the other font-lock-keywords. > I'm not sure whether that will work properly at the moment (I suspect it > won't), but I think it can be and should be fixed. I'm thinking about > a piece of badly formatted C code something like: > 1. int foo (int > 2. bar) {printf "Hello world"} ; int baz > 3. (int omg) { > The "baz" on L3 hasn't a snowball's chance in Hades of getting fontified > with f-l-function-name-face unless the font lock region is allowed to > start at the "int" on L2. Why? After all, when you open the file, the region will start at BOB. Stefan