[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs revision #107149

From: Alan Mackenzie
Subject: Re: Emacs revision #107149
Date: Sun, 12 Feb 2012 22:22:38 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

Evening, Lars.

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

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

> > 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

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).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]