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: Mon, 13 Feb 2012 22:07:47 +0000 Message-ID: <20120213220746.GF26954@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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1329170896 30422 80.91.229.3 (13 Feb 2012 22:08:16 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Feb 2012 22:08:16 +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 Mon Feb 13 23:08:15 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 1Rx44E-0003fx-MT for ged-emacs-devel@m.gmane.org; Mon, 13 Feb 2012 23:08:14 +0100 Original-Received: from localhost ([::1]:54982 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rx44E-0000uk-2G for ged-emacs-devel@m.gmane.org; Mon, 13 Feb 2012 17:08:14 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:35057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rx44B-0000uf-4x for emacs-devel@gnu.org; Mon, 13 Feb 2012 17:08:12 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rx44A-0000k9-3Z for emacs-devel@gnu.org; Mon, 13 Feb 2012 17:08:11 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:45833 helo=mail.muc.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rx449-0000ju-PV for emacs-devel@gnu.org; Mon, 13 Feb 2012 17:08:10 -0500 Original-Received: (qmail 81682 invoked by uid 3782); 13 Feb 2012 22:08:08 -0000 Original-Received: from acm.muc.de (pD951B712.dip.t-dialin.net [217.81.183.18]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 13 Feb 2012 23:08:05 +0100 Original-Received: (qmail 6506 invoked by uid 1000); 13 Feb 2012 22:07:47 -0000 Content-Disposition: inline In-Reply-To: <87aa4m5tv1.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:148590 Archived-At: Hi, Lars. On Mon, Feb 13, 2012 at 10:03:14PM +0100, Lars Ingebrigtsen wrote: > Alan Mackenzie writes: > >> Why not just call `(default-value 'font-lock-fontify-region-function)' > >> unconditionally? > > It's unclean programming, and won't work properly under XEmacs. > 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? > Or is it set to something else under XEmacs (in code that's not in the > Emacs 24 tree)? No, it's identical in XEmacs. Anyhow, you've neglected to address the main points in my last post. Would you please do so now: >>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 So, how about this patch? Would it work for what you need to do? As yet, I've no clear understanding of what your mode is trying to do here, or why. I'd appreciate you filling in the gaps for me. >>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. 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? >>The point is, you are reaching into other major modes and messing them >>up to an unknown extent. This is not good programming practice. This is the main point. You are knowingly sabotaging the initialisation of modes that you use. This is bad. Please respond to this point. Evening, Lars. -- Alan Mackenzie (Nuremberg, Germany).