[Top][All Lists]

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

Re: Font-lock in COMINT modes

From: JD Smith
Subject: Re: Font-lock in COMINT modes
Date: Fri, 08 Dec 2006 19:15:50 -0700
User-agent: Pan/ (As She Crawled Across the Table)

On Fri, 08 Dec 2006 20:26:27 -0500, Richard Stallman wrote:

>     Here is the change which altered the default behavior in comint modes.
>     ----------------------------
>     revision 1.348
>     date: 2006-09-28 19:09:19 +0000;  author: rms;  state: Exp;  lines: +4
>     -1 (comint-mode): Bind font-lock-defaults non-nil.
>     ----------------------------
> I'm sure I did this to fix a bug, but I can't find any discussion about
> it.  Maybe it was so facemenu-enable-faces-p would return nil.
> As far as I can see, if font-lock-defaults is nil, that is equivalent to
> (nil).  How do you conclude that nil would be equivalent to (nil t)?

nil and '(nil) are not equivalent, in that the former implicitly
causes only keywords to be fontified, and the latter causes
font-lock-keywords-only to be set locally to nil (since it is a list
without a 2nd entry), which allows string and comments to be

This is a telling comment from font-core.el:

  ;; Only do hard work if the mode has specified stuff in
  ;; `font-lock-defaults'.

All the defaults, like keyword-only, are recovered from the
font-lock-defaults list *only* if it is non-nil (e.g. '(nil)).  I
haven't understood how a purely nil font-lock-defaults implicitly
prevents string+comment fontification independent of the keywords-only
setting, but it does.

'(nil t) explicitly sets keywords-only to t, restoring the behavior.
What I don't know is whether nil and '(nil t) differ in other ways.
They clearly exercise different code paths.


reply via email to

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