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: Sat, 11 Feb 2012 19:59:27 +0000 Message-ID: <20120211195927.GA3969@acm.acm> References: <20120210232039.GC4340@acm.acm> <87pqdlbby2.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 1328990397 4496 80.91.229.3 (11 Feb 2012 19:59:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 11 Feb 2012 19:59:57 +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 Sat Feb 11 20:59:57 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 1RwJ6w-0005gV-Je for ged-emacs-devel@m.gmane.org; Sat, 11 Feb 2012 20:59:54 +0100 Original-Received: from localhost ([::1]:51973 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwJ6w-0005o4-2h for ged-emacs-devel@m.gmane.org; Sat, 11 Feb 2012 14:59:54 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:40268) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwJ6t-0005no-5W for emacs-devel@gnu.org; Sat, 11 Feb 2012 14:59:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RwJ6s-0006jo-7E for emacs-devel@gnu.org; Sat, 11 Feb 2012 14:59:51 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:63639 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RwJ6r-0006je-Qe for emacs-devel@gnu.org; Sat, 11 Feb 2012 14:59:50 -0500 Original-Received: (qmail 22701 invoked by uid 3782); 11 Feb 2012 19:59:47 -0000 Original-Received: from acm.muc.de (pD951A921.dip.t-dialin.net [217.81.169.33]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 11 Feb 2012 20:59:44 +0100 Original-Received: (qmail 3996 invoked by uid 1000); 11 Feb 2012 19:59:27 -0000 Content-Disposition: inline In-Reply-To: <87pqdlbby2.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:148480 Archived-At: Hello, Lars. On Sat, Feb 11, 2012 at 04:56:53PM +0100, Lars Ingebrigtsen wrote: > Alan Mackenzie writes: > > Why, should the case be, would you want to call font-lock-fontify-buffer > > without initialising font lock mode first? Would this not, perhaps, > > indicate some other problem in mm-inline-text? > mm sets `font-lock-mode-hook' (and friends) to nil to avoid problems > when calling `(font-lock-fontify-buffer)', if I remember correctly. You cannot get away with this. These hooks belong to the major mode (or perhaps the user), and if you arbitrarily inhibit them, then font lock, in the general case, will not be fully initialised. > Since it's that hook that sets > `c-standard-font-lock-fontify-region-function' (which is nil by > default), this breaks when viewing C mode files. Again, why are you breaking these hook calls? This seems to be a very bad solution to whatever the problem was. > Is there any reason why `c-standard-font-lock-fontify-region-function' > is nil, when this makes just calling `(font-lock-fontify-buffer)' not > work? font-lock-fontify-region will work fine if you just initialise font lock fully. That involves running the hook. > All the other modes seem to work fine. Then you've been lucky, so far. What in mm gets upset by running font-lock-mode-hook? Setting that variable to font-lock-default-fontify-region at build time couples CC Mode and font lock mode too closely. In particular, it will prevent CC Mode loading on any system in which font lock is not present. -- Alan Mackenzie (Nuremberg, Germany).