unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#635: Adding font-lock keywords results in no font-lock at all
@ 2008-08-01  6:21 Klaus Zeitler
  2008-08-05 13:12 ` martin rudalics
  2010-10-09  4:11 ` Chong Yidong
  0 siblings, 2 replies; 6+ messages in thread
From: Klaus Zeitler @ 2008-08-01  6:21 UTC (permalink / raw)
  To: bug-gnu-emacs


For many years I had the following statement in my .emacs file:

(defun show-tabs () "Show tabs with a slightly changed background"
  (font-lock-add-keywords nil '(("\t"  (0 'tab-face t))) t))
(add-hook 'font-lock-mode-hook 'show-tabs)

This has worked without any problems up to 22.1.
In version 22.2 and 23 I do have problems with syntax highlighting due
to these few lines above in some modes, e.g. when I try M-x list-faces-display
all colors are gone.

To reproduce:

1. start "emacs -Q"
2. in scratch buffer evaluate
(defun show-tabs () "Show tabs with a slightly changed background"
  (font-lock-add-keywords nil '(("\t"  (0 'font-lock-constant-face t))) t))
(add-hook 'font-lock-mode-hook 'show-tabs)
3. M-x list-faces-display
=> everything's displayed in default face



In GNU Emacs 22.2.2 (sparc-sun-solaris2.8, Motif Version 2.1.0)
 of 2008-04-09 on sfsws4
Windowing system distributor `Sun Microsystems, Inc.', version 11.0.6410
configured using `configure  '--with-gcc' '--prefix=/vol/freeware/SunOS-5.8/emacs/22.2' '--sharedstatedir=/vol/freeware/SunOS-5.8/emacs/22.2/share' '--with-x-toolkit=motif' '--x-includes=/usr/openwin/include:/usr/local/gnu/include:/opt/exp/gnu/include:/opt/exp/include:/opt/exp/lib/xpm/include' '--x-libraries=/usr/openwin/lib:/usr/local/gnu/lib:/opt/exp/gnu/lib:/opt/exp/lib:/opt/exp/lib/xpm/lib' '--with-pop' 'CC=gcc' 'XMKMF=/usr/openwin/bin/xmkmf''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
("emacs" "-Q")
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading emacsbug...
Loading regexp-opt...done
Loading emacsbug...done








^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#635: Adding font-lock keywords results in no font-lock at all
  2008-08-01  6:21 Klaus Zeitler
@ 2008-08-05 13:12 ` martin rudalics
  2008-08-12  6:43   ` Klaus Zeitler
  2010-10-09  4:11 ` Chong Yidong
  1 sibling, 1 reply; 6+ messages in thread
From: martin rudalics @ 2008-08-05 13:12 UTC (permalink / raw)
  To: Klaus Zeitler, 635; +Cc: bug-gnu-emacs

 > For many years I had the following statement in my .emacs file:
 >
 > (defun show-tabs () "Show tabs with a slightly changed background"
 >   (font-lock-add-keywords nil '(("\t"  (0 'tab-face t))) t))
 > (add-hook 'font-lock-mode-hook 'show-tabs)
 >
 > This has worked without any problems up to 22.1.
 > In version 22.2 and 23 I do have problems with syntax highlighting due
 > to these few lines above in some modes, e.g. when I try M-x list-faces-display
 > all colors are gone.

The behavior you observe seems due to the change

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.


Get your original behavior back by writing something like

(defun show-tabs () "Show tabs with a slightly changed background"
   (unless (or font-lock-keywords font-lock-defaults)
     (set (make-local-variable 'font-lock-defaults) '(nil t)))
   (font-lock-add-keywords nil '(("\t"  (0 'tab-face t))) t))
(add-hook 'font-lock-mode-hook 'show-tabs)

or by removing the offending lines from font-lock.el ;-(

martin







^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#635: Adding font-lock keywords results in no font-lock at all
  2008-08-05 13:12 ` martin rudalics
@ 2008-08-12  6:43   ` Klaus Zeitler
  0 siblings, 0 replies; 6+ messages in thread
From: Klaus Zeitler @ 2008-08-12  6:43 UTC (permalink / raw)
  To: martin rudalics; +Cc: 635, bug-gnu-emacs

>>>>> "martin" == martin rudalics <rudalics@gmx.at> writes:
    martin> 
    martin> Get your original behavior back by writing something like
    martin> 
    martin> (defun show-tabs () "Show tabs with a slightly changed background"
    martin>   (unless (or font-lock-keywords font-lock-defaults)
    martin>     (set (make-local-variable 'font-lock-defaults) '(nil t)))
    martin>   (font-lock-add-keywords nil '(("\t"  (0 'tab-face t))) t))
    martin> (add-hook 'font-lock-mode-hook 'show-tabs)

Yes, it works now again as expected.

    martin> or by removing the offending lines from font-lock.el ;-(

I can live with your workaround till it's fixed :-).

Thanks a lot for your help.

Klaus

-- 
 --------------------------------------------------
|  Klaus Zeitler      Alcatel-Lucent               |
|  Email:             kzeitler@alcatel-lucent.com  |
 --------------------------------------------------
---
Biology is the only science in which multiplication
means the same thing as division.







^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#635: Adding font-lock keywords results in no font-lock at all
@ 2009-08-13 23:41 Chong Yidong
  2009-08-19  0:14 ` Stefan Monnier
  0 siblings, 1 reply; 6+ messages in thread
From: Chong Yidong @ 2009-08-13 23:41 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: 635

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

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?





^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#635: Adding font-lock keywords results in no font-lock at all
  2009-08-13 23:41 bug#635: Adding font-lock keywords results in no font-lock at all Chong Yidong
@ 2009-08-19  0:14 ` Stefan Monnier
  0 siblings, 0 replies; 6+ messages in thread
From: Stefan Monnier @ 2009-08-19  0:14 UTC (permalink / raw)
  To: Chong Yidong; +Cc: 635

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






^ permalink raw reply	[flat|nested] 6+ messages in thread

* bug#635: Adding font-lock keywords results in no font-lock at all
  2008-08-01  6:21 Klaus Zeitler
  2008-08-05 13:12 ` martin rudalics
@ 2010-10-09  4:11 ` Chong Yidong
  1 sibling, 0 replies; 6+ messages in thread
From: Chong Yidong @ 2010-10-09  4:11 UTC (permalink / raw)
  To: 635-done

I've just checked in a patch by David Koppelman which should fix this:

http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00239.html





^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2010-10-09  4:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-08-13 23:41 bug#635: Adding font-lock keywords results in no font-lock at all Chong Yidong
2009-08-19  0:14 ` Stefan Monnier
  -- strict thread matches above, loose matches on Subject: below --
2008-08-01  6:21 Klaus Zeitler
2008-08-05 13:12 ` martin rudalics
2008-08-12  6:43   ` Klaus Zeitler
2010-10-09  4:11 ` Chong Yidong

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).