Re: Font-lock in COMINT modes

[JD Smith]

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

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.

JD