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: Emacs revision #107149 Date: Tue, 21 Feb 2012 15:16:11 +0000 Message-ID: <20120221151611.GB2787@acm.acm> References: <20120210232039.GC4340@acm.acm> <87pqdlbby2.fsf@gnus.org> <20120211195927.GA3969@acm.acm> <87zkcnhjfw.fsf@gnus.org> <20120212222238.GA2810@acm.acm> <87aa4m5tv1.fsf@gnus.org> <20120213220746.GF26954@acm.acm> <877gzh6dek.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1329837430 14054 80.91.229.3 (21 Feb 2012 15:17:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 21 Feb 2012 15:17:10 +0000 (UTC) Cc: bug-cc-mode@gnu.org, emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 21 16:17:08 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RzrSi-0007xm-BS for ged-emacs-devel@m.gmane.org; Tue, 21 Feb 2012 16:17:04 +0100 Original-Received: from localhost ([::1]:39842 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzrSh-00044V-6A for ged-emacs-devel@m.gmane.org; Tue, 21 Feb 2012 10:17:03 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:47153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzrSZ-00044E-6U for emacs-devel@gnu.org; Tue, 21 Feb 2012 10:17:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzrST-0004k2-8G for emacs-devel@gnu.org; Tue, 21 Feb 2012 10:16:55 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:59786 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzrSS-0004js-RZ for emacs-devel@gnu.org; Tue, 21 Feb 2012 10:16:49 -0500 Original-Received: (qmail 32162 invoked by uid 3782); 21 Feb 2012 15:16:47 -0000 Original-Received: from acm.muc.de (pD9557375.dip.t-dialin.net [217.85.115.117]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 21 Feb 2012 16:16:40 +0100 Original-Received: (qmail 5278 invoked by uid 1000); 21 Feb 2012 15:16:11 -0000 Content-Disposition: inline In-Reply-To: <877gzh6dek.fsf@gnus.org> 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:148696 Archived-At: Hi, Lars. On Mon, Feb 20, 2012 at 10:51:31AM +0100, Lars Ingebrigtsen wrote: > Alan Mackenzie writes: > The fontification takes place in one buffer, and the result is then > copied over to a different buffer. OK, I've got this now. ;-) > > Have you individually checked any of the other modes you might use, to > > make sure that they don't get fouled up by not calling their > > font-lock-mode-hooks? > There have been no bug reports on other modes; just C mode. That's scarcely the point. It's an accident waiting to happen again, just as it has already happened once. > You still haven't responded to my question of why CC mode does the > initialisation of this variable in this rather baroque way: > > You may well be right, but looking at the code, I don't really see why. > > There's one single consumer of > > `c-standard-font-lock-fontify-region-function'? There's one single > > place it's set? If it isn't set, the function breaks unconditionally? If font-lock-fontify-region-function doesn't exist (font-lock-mode hasn't (yet) been loaded (xemacs)), trying to access its value will throw an error. > The code does not seem to make sense as it is, but I may well be > misreading it. The reason for inhibiting font-lock-mode-hook in mm-view-display-inline-fontify is that otherwise one of two functions (turn-on-lazy-lock, turn-on-fast-lock) might get called, and that font-lock-support-mode would prevent the desired immediate fontification of the whole buffer. Solely in XEmacs, of course. Therefore, you don't need to switch off the entire font-lock-mode-hook; you merely have to remove these two functions from it, which can be done very simply by binding font-lock-mode-hook and using remove-hook. Again, please try my patch (after putting `copy-list' into the binding of font-lock-mode-hook ;-). -- Alan Mackenzie (Nuremberg, Germany).