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: Sun, 12 Feb 2012 22:22:38 +0000 Message-ID: <20120212222238.GA2810@acm.acm> References: <20120210232039.GC4340@acm.acm> <87pqdlbby2.fsf@gnus.org> <20120211195927.GA3969@acm.acm> <87zkcnhjfw.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 1329085394 20086 80.91.229.3 (12 Feb 2012 22:23:14 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 12 Feb 2012 22:23:14 +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 Sun Feb 12 23:23:13 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 1RwhpA-0005v4-TO for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2012 23:23:13 +0100 Original-Received: from localhost ([::1]:40950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rwhp7-0003wI-2K for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2012 17:23:09 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:49668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rwhp4-0003w2-33 for emacs-devel@gnu.org; Sun, 12 Feb 2012 17:23:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rwhp2-0000Xp-Pv for emacs-devel@gnu.org; Sun, 12 Feb 2012 17:23:05 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:50803 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rwhp2-0000XT-GA for emacs-devel@gnu.org; Sun, 12 Feb 2012 17:23:04 -0500 Original-Received: (qmail 57536 invoked by uid 3782); 12 Feb 2012 22:23:02 -0000 Original-Received: from acm.muc.de (pD9519EB9.dip.t-dialin.net [217.81.158.185]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 12 Feb 2012 23:22:56 +0100 Original-Received: (qmail 2944 invoked by uid 1000); 12 Feb 2012 22:22:38 -0000 Content-Disposition: inline In-Reply-To: <87zkcnhjfw.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:148530 Archived-At: Evening, Lars. On Sun, Feb 12, 2012 at 09:42:59PM +0100, Lars Ingebrigtsen wrote: > Alan Mackenzie writes: > > 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. > As Wolfgang Jenkner said, I think it has something to do with disabling > the delayed fontification modes. But I'm not actually sure -- the code > has been that way forever, and I probably didn't write it. Try this instead: It solves the actual problem stated in the comment, rather than papering over it: *** mm-view.el~ 2012-02-08 14:25:18.000000000 +0000 --- mm-view.el 2012-02-12 21:50:34.000000000 +0000 *************** *** 601,610 **** (require 'font-lock) ;; I find font-lock a bit too verbose. (let ((font-lock-verbose nil) ! (font-lock-support-mode nil)) ;; Disable support modes, e.g., jit-lock, lazy-lock, etc. ;; Note: XEmacs people use `font-lock-mode-hook' to run those modes. ! (set (make-local-variable 'font-lock-mode-hook) nil) (setq buffer-file-name (mm-handle-filename handle)) (set (make-local-variable 'enable-local-variables) nil) (with-demoted-errors --- 601,612 ---- (require 'font-lock) ;; I find font-lock a bit too verbose. (let ((font-lock-verbose nil) ! (font-lock-support-mode nil) ! (font-lock-mode-hook font-lock-mode-hook)) ;; Disable support modes, e.g., jit-lock, lazy-lock, etc. ;; Note: XEmacs people use `font-lock-mode-hook' to run those modes. ! (remove-hook 'font-lock-mode-hook 'turn-on-fast-lock) ! (remove-hook 'font-lock-mode-hook 'turn-on-lazy-lock) (setq buffer-file-name (mm-handle-filename handle)) (set (make-local-variable 'enable-local-variables) nil) (with-demoted-errors But, do you actually have to suppress these support modes? They're there to fontify text screens faster. Why disable them? Nowadays, with faster HW than ever, it seems pointless even to bother. You've admitted, I think, that you don't know why that code is there. You could just rip it out. > > Again, why are you breaking these hook calls? This seems to be a very > > bad solution to whatever the problem was. > It works for all modes tested, except C mode, apparently. How do you know? font-lock-mode-hook is used by hi-lock mode, cperl-mode, sql mode, ada mode, verilog mode, and CC Mode. One of these is definitely being broken. The others probably are, if you ever use them. The point is, you are reaching into other major modes and messing them up to an unknown extent. This is not good programming practice. > > 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. > What systems would this be? XEmacs, of course, which is the only system you need to mask out turn-on-lazy-lock and friends for. > As far as I can tell from the cc-mode code, `c-font-lock-fontify-region' > unconditionally calls `c-standard-font-lock-fontify-region-function'. > Furthermore, `c-standard-font-lock-fontify-region-function' doesn't seem > to be set to anything other than `(default-value > 'font-lock-fontify-region-function)'. And the variable is not a > user-level variable, which seems to make the entire tap-dance routine > here rather ... odd. > Why not just call `(default-value 'font-lock-fontify-region-function)' > unconditionally? It's unclean programming, and won't work properly under XEmacs. -- Alan Mackenzie (Nuremberg, Germany).