From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.cc-mode.general,gmane.emacs.devel Subject: Re: font-lock-extend-region Date: Mon, 20 Mar 2006 12:18:49 -0500 Message-ID: References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1142875252 2329 80.91.229.2 (20 Mar 2006 17:20:52 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 20 Mar 2006 17:20:52 +0000 (UTC) Cc: "Richard M. Stallman" , Ralf Angeli , martin rudalics , emacs-devel@gnu.org, bug-cc-mode@gnu.org Original-X-From: cc-mode-help-admin@lists.sourceforge.net Mon Mar 20 18:20:47 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 1FLO3D-0004sc-V0 for sf-cc-mode-help@m.gmane.org; Mon, 20 Mar 2006 18:20:16 +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 22E01127A1; Mon, 20 Mar 2006 09:20:15 -0800 (PST) Original-Received: from sc8-sf-mx2-b.sourceforge.net ([10.3.1.92] helo=mail.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1FLO2s-0006w7-N0 for cc-mode-help@lists.sourceforge.net; Mon, 20 Mar 2006 09:19:54 -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 1FLO2o-00025c-25 for cc-mode-help@lists.sourceforge.net; Mon, 20 Mar 2006 09:19:54 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1FLO2Y-0003v1-Kh for bug-cc-mode@gnu.org; Mon, 20 Mar 2006 12:19:34 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1FLO7z-0006rb-IS for bug-cc-mode@gnu.org; Mon, 20 Mar 2006 12:25:14 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FLO7y-0006mV-94; Mon, 20 Mar 2006 12:25:10 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 8C5872CF47E; Mon, 20 Mar 2006 12:18:55 -0500 (EST) Original-Received: from asado.iro.umontreal.ca (asado.iro.umontreal.ca [132.204.24.84]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 17292445C; Mon, 20 Mar 2006 12:18:50 -0500 (EST) Original-Received: by asado.iro.umontreal.ca (Postfix, from userid 20848) id E55C971553; Mon, 20 Mar 2006 12:18:49 -0500 (EST) Original-To: Alan Mackenzie In-Reply-To: (Alan Mackenzie's message of "Mon, 20 Mar 2006 13:01:00 +0000 (GMT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: 0.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 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: Mon, 20 Mar 2006 12:18:49 -0500 Xref: news.gmane.org gmane.emacs.cc-mode.general:3245 gmane.emacs.devel:51892 Archived-At: [ I hope some of this exchange can get into some documentation somewhere. I find it very useful to have to explain it in such details. ] > Before I get going, I'd like to say I've spent some time getting to grips > with jit-lock, and I think I now understand some of the things you were > telling me. I also apologize for getting a bit grumpy about it last > week. Don't worry about it. I've been so edgy these days that I wouldn't notice anyone else getting grumpy. > I think there are two distinct issues here that we're confusing, and this > is why we've found it so hard to agree: > (i) calculating the region which needs refontifying. > (ii) finding a safe place to start fontifying a single chunk. Right. The first is generally handled by jit-lock-context-* (including the jit-lock-defer-multiline property). The second is generally handled by the font-lock-multiline property and by rounding up to a whole number of lines. > font-lock-extend-region-function is intended to do (i). The functionality > you're suggesting for f-l-default-fontify-region is for doing (ii). In other words your use of font-lock-extend-region-function is specifically to deal with issues that jit-lock-context-* tries to handle as well. > I think the essence of the font-lock-multiline property is that it marks > a chunk of text to be fontified atomically. Please confirm this > impression or correct it for me. Correct. > Here's why I think the font-lock-multiline way is wrong. Taking my AWK > example again: > 1. "string \ > 2. over \ > 3. several \ <========= > 4. #lines." > Suppose the user replaces the backslash on L3 with 20k of code from the > kill ring with M-y. The region to fontify now extends from L1 to EOL4 > (actually, it's now L1073). The display engine is going to request > fontification from L1034. If I mark this entire region with > font-lock-multiline, these 1073 lines will be (unnecessarily) fontified > atomically, defeating the aims of jit-lock in this case. The region is not automatically marked with font-lock-multiline, so you can't really fault font-lock-multiline for it: it's your code that marks it that is at fault. [ Now don't get me wrong: the font-lock-multiline property is not perfect. ] > What I think we need is a function called from f-l-default-f-region which > will get a safe starting position at or before L1034. Agreed. And I suggested we name it font-lock-extend-region-function. You seem to be saying that you'd also want such a thing in after-change-functions. My belief is that you don't need it for the following reason: if you need to refontify more than the 20K of code you just yanked, it can only be because of elements at the beginning/end that need to be refontified atomically, so you can just either place a font-lock-multiline property on them or extend the region from f-l-default-fontify-region. But maybe this is only true in theory, and reasons of performance (or presence/absence of various info in different contexts) make it that you do need an "extend-region" in font-lock-after-change-function. Is that what you are saying? Or is there some other reason to extend the region from after-change-functions, other than atomic elements at the boundaries? > What I think we should do is to put a hook into f-l-default-f-region to > calculate a safe starting position (and probably also a safe stopping > position). Yes, we agree on that. > Incidentally, referring to my diagram above, the region gets extended to > whole lines more than once. For demand fontification, it is done first > in jit-lock-fontify-now then in font-lock-default-fontify-region. For > after-change fontification, it is done yet a third time in > jit-lock-after-change. Yes, it's a bit messy, partly for historical reasons. > How about doing this only in f-l-default-f-r? This would make it easier > for a mode maintainer to switch off this action, since he would then just > have to put a modified function into the hook > font-lock-fontify-region-function. I believe the one in jit-lock-fontify-now could be removed (but this function is also sadly called from external packages, so there may be some minor compatibility issues). But the one in jit-lock-after-change is needed because of what the comment there says. Basically here is the scenario: start with C code like void foo and add an open parenthesis at the end. The modified chunk is just the open paren, so if you don't reset the `fontified' property on the whole line, the redisplay engine will not redisplay `foo' and even if jit-lock changes the `face' property on `foo' it does it after the display engine decided what `foo' would look like. So if jit-lock-after-change doesn't round up to whole lines, `foo' in the above scenario would only be refontified at the next screen refresh :-( I'd like to be able to solve this problem elsewhere than in jit-lock-after-change (e.g. some way for jit-lock to say "hey, font-lock modified this text before BEGIN, please make sure you redisplay it immediately"), but even if I knew how to do that, I'd probably not use it for whole-line-round-up because it would simply cause (almost) all redisplay to be done twice. Stefan ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642