Re: Emacs revision #107149

[Alan Mackenzie <acm@muc.de>]

Evening, Lars.

On Sun, Feb 12, 2012 at 09:42:59PM +0100, Lars Ingebrigtsen wrote:
> Alan Mackenzie <acm@muc.de> 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).