emacs-devel
[Top][All Lists]
Advanced

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

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


From: Stefan Monnier
Subject: Re: map: major-mode --> font-lock-defaults
Date: Mon, 29 Jan 2001 17:08:30 -0500

> > * In message <address@hidden>
> > * On the subject of "Re: map: major-mode --> font-lock-defaults "
> > * Sent on Mon, 29 Jan 2001 14:40:53 -0500
> > * Honorable "Stefan Monnier" <monnier+gnu/address@hidden> writes:
> >
> > > 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".
> 
> You mean this is a "read-only" variable?
> I thought that "obsolete" means that it will go away in a future
> version, so one should not use it at all.

It should indeed go away in a future version.
So indeed, don't put stuff in it.  But if a major mode uses it, there's
generally no other place to find that info.

> > > 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.
> 
> isn't this ugly and wasteful (having to create a buffer and set up a
> mode just to get the `font-lock-defaults')?

How often do you need to find the font-lock-defaults _of a mode_ (as
opposed to "of a buffer") ?

> shouldn't there be another way?

Only if it's an operation that's actually used.
The same holds for imenu-generic-expression and comment-start and plenty
of other such variables.

> > > 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.
> 
> wait a second: it was _not_ automatically inherited from c-mode to
> d-mode (yes, you say the reason is administrative, not technical, but
> the bottom line is: it is not _always_ automatically inherited!)

Indeed, the font-lock-defaults-alist method does not automatically inherit,
which is one of its disadvantages.  But I don't see how that's relevant
since I was talking about the method advocated by Emacs which is to set
the font-lock-defaults buffer-local variable (and it's the method that's
been in use for many years, the font-lock-defaults-alist has seen much
less use in comparison even when it wasn't explicitly deprecated).

> what about `lisp-mode' and `emacs-lisp-mode'?
> they are mentioned in `font-lock-defaults-alist', but they are
> maintained by the FSF, right?

Yes.  But note that the value there is "not used any more" since those
modes now set font-lock-defaults themselves anyway.
They are still mentioned in font-lock-defaults-alist for various reasons,
mostly having to do with compatibility.


        Stefan




reply via email to

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