Re: Emacs revision #107149

[Lars Ingebrigtsen <larsi@gnus.org>]

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.

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

>> Is there any reason why `c-standard-font-lock-fontify-region-function'
>> is nil, when this makes just calling `(font-lock-fontify-buffer)' not
>> work?
>
> font-lock-fontify-region will work fine if you just initialise font lock
> fully.  That involves running the hook.

So there is no reason?

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

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?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome