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: Tue, 21 Mar 2006 16:32:10 -0500 Message-ID: <87ek0vem8c.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 1142976942 28846 80.91.229.2 (21 Mar 2006 21:35:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 21 Mar 2006 21:35:42 +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 Tue Mar 21 22:35:41 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 1FLoVp-0000uQ-Sk for sf-cc-mode-help@m.gmane.org; Tue, 21 Mar 2006 22:35:34 +0100 Original-Received: from sc8-sf-list1-b.sourceforge.net (sc8-sf-list1-b.sourceforge.net [10.3.1.7]) by sc8-sf-spam1.sourceforge.net (Postfix) with ESMTP id 42B4D89C9D; Tue, 21 Mar 2006 13:33:03 -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 1FLoSf-0008Oa-Gf for cc-mode-help@lists.sourceforge.net; Tue, 21 Mar 2006 13:32:17 -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 1FLoSd-0008BP-5R for cc-mode-help@lists.sourceforge.net; Tue, 21 Mar 2006 13:32:17 -0800 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1FLoSm-0003An-2b for bug-cc-mode@gnu.org; Tue, 21 Mar 2006 16:32:24 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.52) id 1FLoSo-00051j-Vm for bug-cc-mode@gnu.org; Tue, 21 Mar 2006 16:32:27 -0500 Original-Received: from [209.226.175.110] (helo=tomts43-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FLoSo-00051T-KI; Tue, 21 Mar 2006 16:32:26 -0500 Original-Received: from alfajor ([70.55.140.81]) by tomts43-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060321213211.SVMH4713.tomts43-srv.bellnexxia.net@alfajor>; Tue, 21 Mar 2006 16:32:11 -0500 Original-Received: by alfajor (Postfix, from userid 1000) id D8CB7D73BE; Tue, 21 Mar 2006 16:32:10 -0500 (EST) Original-To: Alan Mackenzie In-Reply-To: (Alan Mackenzie's message of "Tue, 21 Mar 2006 16:05:02 +0000 (GMT)") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on monty-python X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4 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: Tue, 21 Mar 2006 16:32:10 -0500 Xref: news.gmane.org gmane.emacs.cc-mode.general:3253 gmane.emacs.devel:51942 Archived-At: >> 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. ] > Hang on a moment! The CC Mode code _doesn't_ currently mark text with > font-lock-multiline. I understood your suggestion was that it should do > this. My response was to your complaint about font-lock-multiline because of what would happen if the C mode placed a font-lock-multiline on the whole 20K of yanked text. I understand that C mode doesn't do that right now. >>> 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. > font-lock-extend-region-function is already in use for purpose (i), > determining the region to be fontified. Yes, I understand that, but I'm trying to understand why you need it and whether font-lock-extend-region-function is then the right answer. > I'm saying we also need a distinct function for purpose (ii), determining > a safe place to start fontifying a chunk which could easily be in the > middle of the region returned by (i). I think I need to start over. IIUC you're trying to handle the "\\\n" line-continuation feature, right? For that, you need to always font-lock the whole multiline-line at a time, right? So my natural answer (given the hammer I have in my hand) is to tell you to put a font-lock-multiline property on the whole multiline-line. My naive understanding says that it should be sufficient: no need for font-lock-extend-region anywhere. >> Or is there some other reason to extend the region from >> after-change-functions, other than atomic elements at the boundaries? > The region sometimes has to be extended to the end of what was an atomic > element before the change, but is no longer so. If this previously-atomic element had a font-lock-multiline property, then it will be refontified atomically (at which point it will be discovered that it's not atomic anymore so the font-lock-multiline property won't be preserved). >> 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). > I think any text region handled by jit-l-f-now cannot avoid being > processed by f-l-fontify-region. Indeed, as I said, I think it can be removed, although of course we'll then have to update glasses-mode first (which registers itself with jit-lock). I think glasses-mode and font-lock-mode are the only two to use jit-lock. > I don't see this, yet. If 'fontified is cleared only on the new open > paren at position 1055, the display engine calls successively > (jit-lock-function 1055), > (jit-lock-fontify-now 1055 1555), > and (assuming j-l-f-now DOESN'T extend to whole lines) > (run-hook jit-lock-functions 1055 1555), > (font-lock-fontify-region 1055 1555), > (funcall font-lock-fontify-region-function 1055 1555), > (font-lock-default-fontify-region 1055 1555). > Here, in f-l-default-f-r, 1055 is set back to 1044 (BOL), and this whole > line, 1044 - 1056, gets its face properties rearranged. You're right until here. > These then get redisplayed. But this is what doesn't happen. > What am I missing here? When the redisplay engine calls jit-lock-function with arg 1055, it has already redisplayed all the text until 1054 and changes in the buffer that affect text before 1055 will not cause redisplay to restart when it finishes. 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