Re: Emacs revision #107149

[Alan Mackenzie]

Hi, Lars.

On Mon, Feb 20, 2012 at 10:51:31AM +0100, Lars Ingebrigtsen wrote:
> Alan Mackenzie <address@hidden> writes:

> The fontification takes place in one buffer, and the result is then
> copied over to a different buffer.

OK, I've got this now.  ;-)

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

> There have been no bug reports on other modes; just C mode.

That's scarcely the point.  It's an accident waiting to happen again,
just as it has already happened once.

> You still haven't responded to my question of why CC mode does the
> initialisation of this variable in this rather baroque way:

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

If font-lock-fontify-region-function doesn't exist (font-lock-mode hasn't
(yet) been loaded (xemacs)), trying to access its value will throw an
error.

> The code does not seem to make sense as it is, but I may well be
> misreading it.

The reason for inhibiting font-lock-mode-hook in
mm-view-display-inline-fontify is that otherwise one of two functions
(turn-on-lazy-lock, turn-on-fast-lock) might get called, and that
font-lock-support-mode would prevent the desired immediate fontification
of the whole buffer.  Solely in XEmacs, of course.

Therefore, you don't need to switch off the entire font-lock-mode-hook;
you merely have to remove these two functions from it, which can be done
very simply by binding font-lock-mode-hook and using remove-hook.

Again, please try my patch (after putting `copy-list' into the binding of
font-lock-mode-hook ;-).

-- 
Alan Mackenzie (Nuremberg, Germany).