Re: Emacs revision #107149

[Alan Mackenzie]

Hi, Lars.

On Mon, Feb 13, 2012 at 10:03:14PM +0100, Lars Ingebrigtsen wrote:
> Alan Mackenzie <address@hidden> 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).