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: Last steps for pretesting (font-lock-extend-region-function) Date: Tue, 25 Apr 2006 08:33:29 -0400 Message-ID: <87fyk1df9o.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 1145968456 20868 80.91.229.2 (25 Apr 2006 12:34:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 25 Apr 2006 12:34:16 +0000 (UTC) Cc: Richard Stallman , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 25 14:34:12 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 1FYMk4-0001MP-9m for ged-emacs-devel@m.gmane.org; Tue, 25 Apr 2006 14:34:08 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYMk3-0003Iq-NQ for ged-emacs-devel@m.gmane.org; Tue, 25 Apr 2006 08:34:07 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FYMjW-00037S-0a for emacs-devel@gnu.org; Tue, 25 Apr 2006 08:33:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FYMjU-00036d-Vj for emacs-devel@gnu.org; Tue, 25 Apr 2006 08:33:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FYMjU-00036R-MM for emacs-devel@gnu.org; Tue, 25 Apr 2006 08:33:32 -0400 Original-Received: from [209.226.175.54] (helo=tomts10-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FYMlv-0005Bm-Ug; Tue, 25 Apr 2006 08:36:04 -0400 Original-Received: from alfajor ([70.55.144.118]) by tomts10-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060425123330.ZWDI20622.tomts10-srv.bellnexxia.net@alfajor>; Tue, 25 Apr 2006 08:33:30 -0400 Original-Received: by alfajor (Postfix, from userid 1000) id E7A7BD7855; Tue, 25 Apr 2006 08:33:29 -0400 (EDT) Original-To: Alan Mackenzie In-Reply-To: (Alan Mackenzie's message of "Tue, 25 Apr 2006 11:33:55 +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:53377 Archived-At: > I find the elisp manual page which describes font-lock-keywords > ("Search-based Fontification") all but inpenetrable. It's reduced me to > tears on several occasions. I've just spent five minutes looking through > it, trying to find the description of the form you suggested to me: > (".*\\\\\n.*" > (0 (progn (put-text-property (match-beginning 0) (match-end 0) > 'font-lock-multiline t) > nil))) > . I didn't find it. Then the problem isn't font-lock-multiline. Please don't mix up matters. This form is the standard form (except you haven't noticed yet that the FACENAME part of the font-lock-keywords is not a face symbol but an Elisp expression whose value after exavluation should be a face). It's: (MATCHER HIGHLIGHT ...) where MATCHER is ".*\\\\\n.*" and HIGHLIGHT is of the form MATCH-HIGHLIGHT which is of the form (SUBEXP FACENAME [OVERRIDE [LAXMATCH]]) where SUBEXP is 0 and FACENAME is (progn ...). > With respect, Stefan, that's rubbish. You need to know where and how to > write the above Lisp form (the one starting (".*\\\\n.*" ...)) into > f-l-keywords. For me, that's perhaps half an hour to an hour of > frustration trying to find the right place in "Search-based > Fontification". If you don't know how font-lock-keywords work, then learn that first before trying to work on the font-lock support for cc-mode. That'll save you a lot more time. > What about the run-time overhead of having an extra text property over > the entire buffer? It's not over the entire buffer. And I haven't seen any evidence that it's noticeable (especially compared the number of `face' properties or of the `fontified' property added to the whole buffer). > The f-l-e-r-f, as you envisage it (being called only from > f-l-default-fontify-r) will also be called at virtually every buffer > change, since almost every change causes a redisplay. AFAIK, the case where a single change takes place between redisplay is the case where there is no performance issue: it takes place at the user's pace anyway. The important case is when Emacs has more work to do in response to a user's action, i.e. there's more work to be done until the next redisplay. >> Just take a deep breath, a couple of steps back, and try to look at the >> example use of font-lock-multiline above as if it were very simple. > I've tried, but I just don't have the intellectual capability to cope > with such complexity without the greatest of difficulty. The whole point is that you shouldn't have to. It's like recursion (tho not nearly as elegant, I must admit): have faith, don't try to simulate it all in your head, and then it becomes simple. > You obviously do. Complicated nested structures make my eyes glaze over. > There's a good chance I'm not the only Emacs hacker who has this sort > of trouble. Any Emacs hacker that needs to write complex syntax highlighting rules will have to learn it anyway unless he prefers to circumvent font-lock and roll his own instead. Sounds like NIH to me. > There's an assymetry between our positions: by threatening to remove the > f-l-e-r-f hook (after-change version), you're trying to force me to use > the f-l-m mechanism. Yes. > You're trying to impose your taste and judgement on me, and I resent this > quite a lot. I'm as close as it gets to a font-lock maintainer. So from where I stand, you're trying to impose your taste and judgment on me. > I think the f-l-m text property is a revolting kludge, but > I'm not trying to do away with it. I'm happy enough for other hackers to > use it, though I'd rather not have to maintain their code afterwards. > Is there any chance we could bring this discussion to an end, now? The > things we've been talking about are important, but this discussion has > taken up an enormous amount of my time, and probably yours too. We've > both got other urgent things to do. 3 ways this can end: - Richard says that you're right. - You convince me that the a-c-f code is better for some realistic case (e.g. yours). - I remove the hook in a-c-f. > My fix is simpler: to recognise that f-l-default-fontify-region performs > two disparate tasks: (i) Extending the region to be fontified; (ii) > Fontifying this region. By extracting (ii) into a separate function, > that function could be called directly from jit-lock-fontify-now, > bypassing the redundant second massaging of the region. It has to be in font-lock-default-fontify-buffer since ther'es no guarantee this is only called from jit-lock-fontify-now. So you're suggesting to add a redundant call to the extend-region hook. Maybe it's simpler but it's ugly (because of the redundance, and because it adds a dependency between jit-lock and font-lock). > (i) It uses the same hook, font-lock-extend-region-function, as > f-l-after-change-functions, setting the third parameter, OLD-LEN, to nil; > (ii) It uses a distinct hook with a new name, say, > font-lock-extend-chunk-function; > (iii) It usurps the name f-l-e-r-f from its current use, abolishing the > region extension mechanism in the f-l-after-change-f/j-l-after-change. (iv) it reuses the name font-lock-extend-region-function and renames the a-c-f hook to font-lock-after-change-extend-region-function. This will happen hopefully today. At the same time font-lock-after-change-extend-region-function will be moved from font-core to font-lock (where it belongs) and its make-variable-buffer-local call will be removed as well (use make-local-variable manually if you need it). Stefan