bug#635: Adding font-lock keywords results in no font-lock at all

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>>>> "Chong" == Chong Yidong <cyd@stupidchicken.com> writes:

>> 2007-06-11  Stefan Monnier  <monnier@iro.umontreal.ca>
>> * font-lock.el (font-lock-add-keywords): In case font-lock was only
>> half-activated, forcefully activate it completely.
>> 
>> which added the following lines to `font-lock-add-keywords'

>> (when (and font-lock-mode
>> (not (or font-lock-keywords font-lock-defaults)))
>> ;; The major mode has not set any keywords, so when we enabled
>> ;; font-lock-mode it only enabled the font-core.el part, not the
>> ;; font-lock-mode-internal.  Try again.
>> (font-lock-mode -1)
>> (set (make-local-variable 'font-lock-defaults) '(nil t))
>> (font-lock-mode 1))
>> 
>> What happens appears to be that in any mode that does not specify
>> `font-lock-keywords' (like `help-mode' or `view-mode' in your case),
>> (font-lock-mode -1) unfontifies the entire buffer thus removing any
>> faces assigned earlier by, for example, `list-faces-display'.  Since
>> these faces are not reassigned by font-lock you won't get them back
>> either :-(
>> 
>> AFAICT, this change also broke `hi-lock-mode' in such buffers.

> Maybe we should do away with the optimization where font-lock-mode
> avoids calling font-lock-internal when font-lock-defaults is empty.
> The performance benefit is probably negligible.

Maybe that would work, although I'm a bit worried about turn it on in
buffers where font-lock doesn't belong.

E.g. list-faces-display shouldn't be combined with font-lock, IIUC (or
we'd have to change it to use font-lock-face first).

I don't know in which way hi-lock-mode was broken "in such buffers", so
it's hard to say more.  Clearly the current situation is not very
satisfactory, with its many hacks, workarounds, and corner cases, but
I'm not sure this would improve the situation, really.


        Stefan