Re: map: major-mode --> font-lock-defaults

[Stefan Monnier]

> > * In message <address@hidden>
> > * On the subject of "Re: map: major-mode --> font-lock-defaults "
> > * Sent on Mon, 29 Jan 2001 12:20:20 -0500
> > * Honorable "Stefan Monnier" <monnier+gnu/address@hidden> writes:
> >
> > > Unfortunately, I do not observe this.
> > > The following:
> > > 
> > > (define-derived-mode d-mode c-mode "D"
> > 
> > Note that c-mode still uses font-lock-defaults-alist.  This is because
> > it's a bit more difficult to move it back into CC-mode (the font-lock
> > regexps for it currently live in font-lock.el) because of the
> > independent maintainership.
> 
> great, this explains the reason for the bug, but not how to work around
> it without using `font-lock-defaults-alist'.

The "don't use" here means "don't put anything there" rather than "don't
look at it".

> > And no, derived.el does not need to do anything special for
> > font-lock-defaults to be inherited.  That's why it's "the right way"
> > (as opposed to font-lock-defaults-alist where you need to inherit
> > things explicitly, as shown in your example).
> 
> fine - but you ignored my question from the previous messages:
> 
> how do I get hold of the `font-lock-defaults' associated with a mode
> without resorting to
>         (with-temp-buffer (c-mode) font-lock-defaults)

That's the only generic way that I know of.

> in particular, what is wrong with using symbol properties, like
>         (get 'c-mode 'font-lock-defaults)

Nothing in particular except that it's not the way chosen by
Emacs' font-lock and since Emacs' way has other advantages (such as
the fact of being automatically inherited), there's little incentive
to change.
I personally don't have a strong preference for either, except maybe
that I don't like symbol properties that much.


        Stefan