bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Stefan Monnier
Subject: bug#635: Adding font-lock keywords results in no font-lock at all
Date: Tue, 18 Aug 2009 20:14:53 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

>>>>> "Chong" == Chong Yidong <address@hidden> writes:

>> 2007-06-11  Stefan Monnier  <address@hidden>
>> * 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






reply via email to

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