From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: command to fontify whole buffer? Date: Thu, 22 Sep 2011 15:27:01 +0000 Message-ID: <20110922152701.GC3134@acm.acm> References: <8BFD7E6B15F149EA96503B2768DFD6C5@us.oracle.com> <20110922143341.GB3134@acm.acm> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1316705488 31325 80.91.229.12 (22 Sep 2011 15:31:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Sep 2011 15:31:28 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 22 17:31:24 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R6lFC-0002ag-17 for ged-emacs-devel@m.gmane.org; Thu, 22 Sep 2011 17:31:22 +0200 Original-Received: from localhost ([::1]:60957 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6lFB-0003wP-6y for ged-emacs-devel@m.gmane.org; Thu, 22 Sep 2011 11:31:21 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:39984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6lF5-0003w7-FF for emacs-devel@gnu.org; Thu, 22 Sep 2011 11:31:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6lEy-0006Ld-J0 for emacs-devel@gnu.org; Thu, 22 Sep 2011 11:31:15 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:41139 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6lEx-0006LI-Sz for emacs-devel@gnu.org; Thu, 22 Sep 2011 11:31:08 -0400 Original-Received: (qmail 8309 invoked by uid 3782); 22 Sep 2011 15:31:03 -0000 Original-Received: from acm.muc.de (pD9556380.dip.t-dialin.net [217.85.99.128]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 22 Sep 2011 17:31:02 +0200 Original-Received: (qmail 4415 invoked by uid 1000); 22 Sep 2011 15:27:01 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:144193 Archived-At: Hi, Drew. On Thu, Sep 22, 2011 at 07:56:52AM -0700, Drew Adams wrote: > > > `font-lock-fontify-buffer' doesn't do it. > > Are you sure? I thought it did, and looking again at the > > fine source, it does appear to. > No, I only think I'm sure. ;-) > After calling `font-lock-fontify-buffer', I can search for zones with face > `font-lock-function-name-face', for example, and I can see that there are no > such zones after some minimal portion of the buffer. Ah. OK. > > > Marking the whole buffer and using > > `(font-lock-fontify-region BEG END)' > > > doesn't do it. > > Ditto. > ditto ditto. > > > Digging more than a bit, I finally found non-interactive function > > > `jit-lock-fontify-now', which seems to do the trick. Why > > > not provide a command that does it? > > jit-lock-fontify-now just calls the function > > font-lock-fontify-region (via a hook) which calls > > font-lock-default-fontify-region (via another hook). > I believe you, but I'm not seeing `font-lock-default-fontify-region' fontify > everything. I'm no expert on this at all. Just going by what I think I see. > > Surely 'fontified DOES do it. If it has the value t throughout the > > buffer, that buffer is fully fontified, otherwise not. > Perhaps you're right that if I checked that property throughout the entire > buffer it would be sufficient. Dunno. I probably didn't try testing it > everywhere. But if that's the best test for full-buffer fontification then I > would still prefer something simpler/quicker. Surely `next-property-change' is going to be fast enough. > > Or have I misunderstood something? > No, no doubt I have. No doubt I still do. ;-) > > By the way, I drew a diagram of how jit-lock works about 5 years ago, > > tracing the functions which call each other, and the hooks > > out of which things get hoiked. Would you be interested in a copy of it? > I guess so; thanks. But I would mostly be interested in confirmation that you > are right etc. I do not see (e.g. by searching for property zones) that the > entire buffer gets fontified by `font-lock-fontify-buffer', but you say it > does/should. OK, here goes. Bear in mind it's five years old. ######################################################################### (i) DEMAND. This is a call from the display engine to fontify a bit of the buffer. JIT either fontifies immediately, or sets 'fontified to 'defer, invoking deferred fontification ((iii)). (ii) STEALTH. This is fontification which happens during idleness. (iii) DEFERRED. After a (short, ~0.25 second) idleness period, deferred bits (from demand ((i))) get 'fontified set to nil. WHOOPS! This leads to an (iv) CONTEXT. After a change, 'fontified is marked nil on the buffer from that point on. Intended for unmatched string openers, etc. (v) AFTER CHANGE. On a buffer change, the 'fontified property on the pertinent text is set to nil. "*" means that the routine adjusts the region to whole lines. DEMAND (called by display code) <----------------------------| [fontification-functions] (hook) | jit-lock-function ->-| | |-------------<------------+ ? | | | | | v ^ | |-----------<------------| | | | | | |->* jit-lock-fontify-now <----------------------------| | | jit-lock-functions (hook) | | v font-lock-fontify-region <------------------------+---+----| | [font-lock-fontify-region-function] (hook) | | | | * font-lock-default-fontify-region | | | | | | | |DEFERRED (invoked by jit-lock-defer-timer) | | | |--> jit-lock-deferred-fontify ------------------>-----+---| | This sets 'fontified to nil, and calls sit-for, | | | causing immediate display (by DEMAND). | | | | | | STEALTH (invoked by jit-lock-stealth-timer | | | jit-lock-stealth-fontify | ^ | jit-lock-fontify-now ----------------->-------------| | | | | CONTEXT (invoked by jit-lock-context-timer) | | jit-lock-context-fontify (from timer) -------->---------+ | This sets 'fontified to nil on the (extended) | | region. | | | | JIT AFTER CHANGE (called from the after-change hook) | ^ * jit-lock-after-change --------------->------------------| | This sets 'fontified to nil, and relies on DEMAND | to refontify the changed bit during display. | | ORDINARY AFTER CHANGE (without jit) | * font-lock-after-change-function | font-lock-fontify-region ---------------->-------------------| | COMMANDS | font-lock-fontify-block | font-lock-fontify-region ---------------->-------------------| | font-lock-fontify-buffer | [font-lock-fontify-buffer-function] (hook) | font-lock-default-fontify-buffer | font-lock-fontify-region ---------------->-------------------| ######################################################################### Interpretation: Of the five possible triggers (e.g. DEMAND) for fontification, this shows the sequence of functions triggered by each of them. [Symbols] in brackets are hook variables. As you surmise above, jit-lock-fontify-now is the central function which actually gets the fontification done. -- Alan Mackenzie (Nuremberg, Germany).