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: font-lock-extend-region (was: [sigra@home.se: C++-mode: Syntax highlighting: wrong color for function identifier depending on the kind of whitespace that follows]) Date: Mon, 20 Mar 2006 03:16:28 -0500 Message-ID: <87wteph7kg.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 1142842621 13747 80.91.229.2 (20 Mar 2006 08:17:01 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Mar 2006 08:17:01 +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 Mon Mar 20 09:16:59 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 1FLFZS-0006b4-1r for ged-emacs-devel@m.gmane.org; Mon, 20 Mar 2006 09:16:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FLFZR-0003v4-Cy for ged-emacs-devel@m.gmane.org; Mon, 20 Mar 2006 03:16:57 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FLFZA-0003uG-Bw for emacs-devel@gnu.org; Mon, 20 Mar 2006 03:16:40 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FLFZ9-0003tL-8g for emacs-devel@gnu.org; Mon, 20 Mar 2006 03:16:39 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FLFZ9-0003t7-2n for emacs-devel@gnu.org; Mon, 20 Mar 2006 03:16:39 -0500 Original-Received: from [209.226.175.97] (helo=tomts40-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FLFeX-0006Lt-24; Mon, 20 Mar 2006 03:22:13 -0500 Original-Received: from alfajor ([70.55.140.81]) by tomts40-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060320081630.JUGK1823.tomts40-srv.bellnexxia.net@alfajor>; Mon, 20 Mar 2006 03:16:30 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id 1780ED73BE; Mon, 20 Mar 2006 03:16:28 -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:51874 Archived-At: > 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. OK, having thought some more about it, I'm really convinced doing it in after-change-function is the wrong way: your jit-lock code won't always do the right thing, because even though you mark the whole extended region for refontification, jit-lock may refontify it in chunks (and maybe not even in the intended order). So I will move the font-lock-extend-region code to font-lock-default-fontify-region where it belongs (which is why that's also the place where font-lock-extra-lines was handled and where font-lock-multiline is handled). Now IIUC that means it'll break some/all of your uses of that variable. Clearly you won't be pleased, but think about it this way: it'll save you bug reports from users seeing odd behavior in conjunction with jit-lock. Anyway, as I said, for your use case what you should be using is an after-change-functions hook that puts a font-lock-multiline property. But as you noted, this will only work if your hook happens to be placed in after-change-functions before font-lock's own (or jit-lock's, though that one is much less serious). Also as I mentioned elsewhere, another solution is to change your requirement such that some of the responsibility of the refontification is passed on to contextual refontification: I would tend to prefer this solution myself (it moves work away from the time-critical path). But admittedly, setting jit-lock-context-time to 0 is believed to be a bit too costly right now (not enough optimizations), so if you really want the refontification to be immediate (rather than delayed by 0.5 idle seconds), it's not a good solution. So what I offer you is to introduce a new `font-lock-before-after-change-functions' which is just like after-change-functions except it's run by font-lock's (or jit-lock's) after-change-function and before it does anything else. You can then use this hook to place a function that computes the extended region and places a font-lock-multiline property on it. Do we have a deal? Stefan