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: Excessive refontification when setting jit-lock-context-unfontify-pos Date: Fri, 27 Apr 2007 14:54:00 -0400 Message-ID: References: <87bqhdaajz.fsf@neutrino.caeruleus.net> <877is1wjti.fsf@neutrino.caeruleus.net> <87ps5tufmf.fsf@neutrino.caeruleus.net> <87k5vxvh4x.fsf@neutrino.caeruleus.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1177700055 32182 80.91.229.12 (27 Apr 2007 18:54:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 27 Apr 2007 18:54:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ralf Angeli Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 27 20:54:13 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1HhVa7-0000Gk-Rj for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2007 20:54:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HhVfz-0000LG-Ol for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2007 15:00:15 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HhVfw-0000LB-Ba for emacs-devel@gnu.org; Fri, 27 Apr 2007 15:00:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HhVfu-0000Kz-R7 for emacs-devel@gnu.org; Fri, 27 Apr 2007 15:00:11 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HhVfu-0000Kw-KC for emacs-devel@gnu.org; Fri, 27 Apr 2007 15:00:10 -0400 Original-Received: from x253-3.xtpr.umontreal.ca ([132.204.253.3] helo=ceviche.home) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HhVa1-0001hx-Nd for emacs-devel@gnu.org; Fri, 27 Apr 2007 14:54:05 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 0EAEFB401D; Fri, 27 Apr 2007 14:54:00 -0400 (EDT) In-Reply-To: <87k5vxvh4x.fsf@neutrino.caeruleus.net> (Ralf Angeli's message of "Fri\, 27 Apr 2007 19\:53\:02 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.97 (gnu/linux) X-detected-kernel: Linux 2.6 (newer, 3) 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:70276 Archived-At: >>> That's what I do. (See `font-latex-fontify-region'.) But the >>> multiline construct does not get fully highlighted if I don't set >>> j-l-c-u-p or set the fontified property to nil. >> >> Try C-l to make sure that the highlighting is really absent from the buffer, >> rather than merely being "not yet displayed". > When typing `C-l' highlighting appears. Is there a possibility to > enforce such redisplay in an efficient way? I could probably call > `sit-for' somewhere in the code but I am not sure if this would be the > right way. I understand the problem, then. Your code is working fine, it's just that some part of the text your re-highlight is re-highlighted by jit-lock but *after* having been rendered by the redisplay engine. Typically it works like this: 1 - you modify buffer on line starting at position POS 2 - the redisplay engine see that there's nothing to do before POS, and calls jit-lock starting at POS. 3 - jit-lock calls font-lock, asking it to refontify region POS..POS+N 4 - font-lock decides to extend the region to POS-M1 .. POS+N+M2 5 - after highlighting is done, control returns to the redisplay which goes on to render POS .. POS+N. The text between POS-M1 and POS has been refontified but the display does not (yet) reflect it. jit-lock has code already to handle similar problems, but the code doesn't handle this case yet (basically because font-lock currently does not tell jit-lock that it has extended the region). The relevant code is in jit-lock-fontify-now: ;; The redisplay engine has already rendered the buffer up-to ;; `orig-start' and won't notice if the above jit-lock-functions ;; changed the appearance of any part of the buffer prior ;; to that. So if `start' is before `orig-start', we need to ;; cause a new redisplay cycle after this one so that any changes ;; are properly reflected on screen. ;; To make such repeated redisplay happen less often, we can ;; eagerly extend the refontified region with ;; jit-lock-after-change-extend-region-functions. (when (< start orig-start) (run-with-timer 0 nil 'jit-lock-force-redisplay (current-buffer) start orig-start)) So in your case you can either use jit-lock-after-change-extend-region-functions; or you can use a similar run-with-timer in your font-lock-fontify-region-function. If you look at jit-lock-force-redisplay, you'll see that it should not cause infinite looping because it only causes redisplay (like C-l would) but not re-highlighting. Of course you can also indeed use jit-lock-context-unfontify-pos, but it has the disadvantage of causing an unnecessary refontification and requires extra care to avoid infinite looping. Also it introduces a delay. In Emacs>22 we should fix the font-lock/jit-lock interface so that jit-lock can handle this case automatically. Stefan