From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel,gmane.emacs.help Subject: Re: Multiline font lock questions Date: Sun, 19 Nov 2006 14:21:42 -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 1163964128 21587 80.91.229.2 (19 Nov 2006 19:22:08 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 19 Nov 2006 19:22:08 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 19 20:22:04 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 1GlsEt-0002oy-HL for ged-emacs-devel@m.gmane.org; Sun, 19 Nov 2006 20:22:03 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GlsEs-000592-NF for ged-emacs-devel@m.gmane.org; Sun, 19 Nov 2006 14:22:02 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GlsEb-00051f-Vz for emacs-devel@gnu.org; Sun, 19 Nov 2006 14:21:46 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GlsEa-0004yd-6J for emacs-devel@gnu.org; Sun, 19 Nov 2006 14:21:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GlsEa-0004yN-0E; Sun, 19 Nov 2006 14:21:44 -0500 Original-Received: from [209.226.175.74] (helo=tomts20-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GlsEZ-0006jt-RY; Sun, 19 Nov 2006 14:21:44 -0500 Original-Received: from pastel.home ([70.55.143.67]) by tomts20-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20061119192142.LZPW16051.tomts20-srv.bellnexxia.net@pastel.home>; Sun, 19 Nov 2006 14:21:42 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 994288282; Sun, 19 Nov 2006 14:21:42 -0500 (EST) Original-To: help-gnu-emacs@gnu.org In-Reply-To: (David Abrahams's message of "Fri\, 17 Nov 2006 09\:08\:33 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.90 (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:62486 gmane.emacs.help:38824 Archived-At: [ Since this refers to doc and vars that are specific to Emacs-22, it might be better to discuss it on emacs-devel. ] > There are three ways to ensure correct identification of multiline > constructs: > * Place a `font-lock-multiline' property on the construct when it is > added to the buffer. > I don't understand how that can help. Indeed, it's a bit awkwardly placed and written. This is basically saying "you can do it yourself manually somehow". > * Use `font-lock-fontify-region-function' hook to extend the scan so > that the scanned text never starts or ends in the middle of a > multiline construct. > That's understandable; I suppose I can just change the region > boundaries to encompass any paragraphs that intersect the region and > then forward on to font-lock-default-fontify-region (?) Right. > * Add a function to `font-lock-extend-region-functions' that does > the _identification_ and extends the scan so that the scanned text > never starts or ends in the middle of a multiline construct. > This is presumably just a way to do the same thing as the above, only > more cooperatively (?) Indeed. But this new var only exists in Emacs-22, so if you want your code to work with Emacs-21, you should use font-lock-fontify-region-function instead. > There are three ways to do rehighlighting of multiline constructs: > * Place a `font-lock-multiline' property on the construct. This > will rehighlight the whole construct if any part of it is changed. > In some cases you can do this automatically by setting the > `font-lock-multiline' variable. > In which cases? Oh, I see that if I read the next info page it will > tell me. I suggest a link or something here. Thanks. > * Use `jit-lock-contextually'.... > What does "Use" mean? I suppose "set it to non-nil," but I had to > guess that jit-lock-contextually was a variable; I suggest a doc tweak. Problem is: in 99% of the cases, it's already set, so there's nothing to do really, other than rely on it doing its job. That's why I set "use". > ...This will only rehighlight the part > of the construct that follows the actual change, and will do it > after a short delay. This only works if the highlighting of the > various parts of your multiline construct never depends on text in > subsequent lines. Since `jit-lock-contextually' is activated by > default, this can be an attractive solution. > That clearly wouldn't work for the example I showed above. Indeed. > * Place a `jit-lock-defer-multiline' property on the construct. > This works only if `jit-lock-contextually' is used, but it can > handle the case where highlighting depends on subsequent lines. > That seems like it could make it work. What's the advantage of using > this method? Over what? `font-lock-multiline'? > Doesn't slow down typing as much? Yes: the re-highlighting is delayed a little bit (see jit-lock-context-time), so it doesn't happen after every keystroke. For small multiline elements, it's not a big change, but for larger ones, it can be significant. Another difference is that it only works if font-lock uses jit-lock. > This very page links to another page describing > font-lock-extend-after-change-region-function, which seems like it > constitutes a fourth way to "do rehighlighting of multiline constructs." Indeed. Alan McKenzie likes this, but I would rather discourage its use. Stefan