GNU bug report logs - #635
Adding font-lock keywords results in no font-lock at all

Previous Next

Full log

Message #34 received at 635 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier  <monnier <at> iro.umontreal.ca>
Cc: martin rudalics <rudalics <at> gmx.at>,
        Klaus Zeitler <kzeitler <at> alcatel-lucent.com>,
        635 <at> debbugs.gnu.org
Subject: Re: bug#635: Adding font-lock keywords results in no font-lock at all
Date: Thu, 13 Aug 2009 19:41:46 -0400

> 2007-06-11  Stefan Monnier  <monnier <at> 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.

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

Stefan, WDYT?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.